We asked our disability services office to review the webmail's accessibility. The manager of that office was a blind woman, who was both a staff member and a student, so she had her own personal student account. She told us she couldn't use Sun's webmail, it wouldn't work at all with her screen reader. We complained to Sun, their response was "we know, wait for the next major version".

What did we do? We offered her a shell account on a Solaris box with Pine, and told her that we'd offer the same to any vision-impaired students or staff members who requested it. And she was happy with that solution.

IANAL a lawyer, but from my understanding of disability discrimination law (which is different in different countries anyway), you are legally obliged to offer "reasonable accomodations" – which doesn't have to necessarily be by making the application accessible, it could be offering access to an alternative application instead.

Also, you are only obliged to provide accessibility if a disabled user asks for it, which assumes you have a user with a relevant disability – if your application is sufficiently niche, that might never happen. Suppose you build an internal GUI for SREs to use. Do you need to make that accessible for the vision impaired? Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation.

I don't completely disagree with you, I think accessibility is often a spectrum, and it's good to be thinking in terms of what your specific accessibility needs are, rather than just going for a scattergun approach.

That said, I have some problems with this example.

Firstly, a lot of features end up in the "accessibility" bin that are more broadly useful (the "cut curb effect"). Your SREs might be fully sighted and mobile, but they will probably still appreciate being able to drive the software fully by keyboard. And even from a development perspective, I've found having correct aria roles etc can often be useful for end-to-end testing because it allows you to be more semantic with the tests ("click on the thing with a button role with the text 'submit'" rather than "click on the element with the ID '...'").

Secondly, we often see accessibility in terms of the extreme cases ("you are blind, you have unlocked the accessibility treatment now"), but accessibility is more broad than that. If you're working late at night in a dark room, or trying to do something on a small laptop screen, or you were out climbing and now your wrists ache, you might still appreciate accessibility features - zooming, keyboard navigation, accessible themes etc. Getting this stuff right helps everyone.

Finally, retrofitting accessibility is often a nightmare to actually implement, because (a) it's hard to notice what's not working unless you go through everything with a fine-toothed comb, and (b) if you don't have at least some accessibility plans to start with, you might have dug yourself into a corner that you can't get out of. For example, if your gui framework has no accessibility support, and someone blind starts in a month's time, what are you going to do? Rewrite the whole application for them?

We talk about accessibility in terms of extremes, because those extremes are where we have legal support that companies can't ignore. The vendors don't want to cut the curb, they want to replace it with a fence and a toll gate. Talking about wheelchairs and strollers lets us prevent the fences, and the toll gates. If they figure they'll skip the curb too, every user wins, but this won't happen without prioritizing wheelchairs, and won't happen if we emphasize regular people too much.

Or, in short, accessibility is the only weapon we have to fight dark patterns and maybe get some ergonomics for everyone.

Didn't downvote but I want to share a couple thoughts I've had about accessibility:

- I assume that browser/electron accessibility is not really optimal for users. It's sort-of free if you're building web/browser stuff, which is nice because it's available by default, but I can imagine most applications could be tailored for accessibility and be much more productive and enjoyable for end-users. For instance a "blind mode" for a text editor would probably be a lot different than what you get out of the box from a screen reader + VS Code. (I would love to get feedback on this from someone using a screen reader or accessibility features.)

- I worry you're providing a bit of a moat if you regulate/require accessible software, since for most applications that equates to using a native GUI toolkit or browser-based solution.

Section 20

You said

>Anyone who would make software with your framework would be in violation of several laws.

Which just isn't true as there are ways you can comply with EQA without every underpinning library being accessibility-compliant.

Say I am a British person who decides to make a some common piece of software, like a spreadsheet, and offer it for download on the internet. Am I required by law to make it accessible? And if, for instance, the provision of accessibility features would require thousands of hours of redevelopment, does that fall under "reasonable adjustments"?

I understand that the moment my software becomes required for someone's job, for instance, there might be a problem, but a few posts up it was implied that making software without accessibility features was in itself illegal in some way, and that just sounds doesn't sound right to me.

Section 20: https://www.legislation.gov.uk/ukpga/2010/15/section/20

That does not call out in its table any reference to software. I can't see anything in it which would effect a binding to software products. Section 22 refers to regulations being able to define what are "auxiliary aids", so in theory an SI may have done so.

Scanning the whole Act, the closest thing I can spot is Schedule 25: https://www.legislation.gov.uk/ukpga/2010/15/schedule/25, however even that defines it as “any service normally provided for remuneration, [...]". Note that is for an online Service, not a Good (which software would generally be). I've also not found what references it.

So that may cover a web site, but only if it was a paid for thing (e.g. online newspaper sites accessed via subscription). I wonder if and how it applies to the likes of Amazon, where the site itself is not paid for, but goods available through it are.

So unless someone can find specific references, I see no reason to believe there is such a statutory requirement in existence for software, certainly not for free software.

(IANAL)

Approach it like that and you have a slight fighting chance because you know what you are getting into.

Funny that you mention Unity because they first had an immediate mode UI that was very difficult to work with, then they got a more flexible UI but decided to go the HTML way of having separate documents for elements and styles, making the whole design process way more complex.

The new input system is powerful and flexible but is slower to learn and makes lots of things that used to be easy much harder.

Same for the new UI Toolkit and several other recent additions. I think it's a company culture thing - nobody internal is rooting for casual devs or noobs.

The problem is - everyone is a noob on something. You might be an incredibly experienced Unity dev who rarely touches input or UI. You want to quickly implement something and you're going to feel the pain.

"Make the easy things easy, and the hard things possible."

People like Apple, Microsoft and browsers put lots of effort into this if you use their existing frameworks right.

Good accessibility capabilities requires flexibility to be at the core of the UI toolkit. You basically can't make assumptions anywhere.

0: https://faultlore.com/blah/text-hates-you/

The compositor. Dealing with ancient Win32 API, with his semi intelligent windows where seemingly every window feature is in weird undocumented ways coupled. Also, the race condition when rendering, just resize any window and see it jiggle. We seem to have collectively given up on fixing it.

Text Input. While not terrible difficult, so many features. From drag and drop, copy / paste, page up / down, CTRL up down left right, Home / End, wrapping. Text is by far the most complex GUI.

To do really nice form layouts in a desktop application, alignment and sizing of labels across the entire form becomes really important to me. Products like Developer Express that have a dedicated form layout work so well for this. And some of the swing layout managers I've used (I can't recall the name, too long ago) make complicated form layouts much more sane than grid, flex and other css layouts.

That might change with .NET MAUI, though. I'm not too deep into it yet, and it is significantly different enough from HTML+CSS to be a challenge to learn, but what I havelearned so far keeps making me question "why did the CSS version of this have to be so hard?"

I even implemented a fair subset of CSS grid:

    parseGridTemplateRows gt, ["row1-start"] 25'pp \
        ["row1-end"] 100'ux \
        ["third-line"] auto ["last-line"]

However, text input is hard and tedious! Then you ideally would need to handle the different keybindings for each OS. You also loose any plugins the OS'es provide. Not to mention the lack of accessibility.

I recall reading that browsers shim out to native OS text fields and wonder how that's done. It really seems like the best approach for small GUI libraries to enabled first class text input.

Ideally the underlying system would offer a low level text rendering API that's independent from the system's UI framework and can be combined with your own rendering efficiently (haven't used it, so don't know how good it actually is, but for instance on Windows there's DirectWrite). The problem with this approach is that not all platforms provide such a modular text renderer (for instance web browsers), and you need different code paths on different platforms (maybe even still have to integrate FreeType because one of the target platforms doesn't expose a text rendering API).

Short of doing a whole CSS rule engine (best) you can also implement a Flutter-like layout system. It is described well by Flutter documentation and is quite flexible.