Hacker News Reader

Comment by dagmx | Hacker News Reader

Accessibility is much more than just labels for a screen reader. Please stop trivializing anything that you don’t use directly, it’s a common thread between all your comments, and it’s a disservice to both the points you’re trying to make and the people who actually use those things .

Accessibility includes interaction design, zoom ability, audio commands, action link ups, alternate rendering modes, alternate motion modes, hooks for assistive devices to interact with the system. It goes far deeper into the system than just labels for a screen reader.

If you stopped to just think about the vast number of disabilities out there, you’d realize how untrue your statement is.

View on HN

All that extra crap doesn't make any sense, when the earliest versions of Windows up to ~7 had controls to let you adjust the UI to exactly how you'd like it, which is of course very important for accessibility.

Then starting with Windows 8, they removed a lot of those features. 11 is even worse.

My point is that accessibility being a thing shouldn't ruin the UI for the people who don't need it. There's no need to visually redesign anything to introduce accessibility. Apps don't need to be made aware whether some control has focus because the user has pressed the tab key, or because it's being focused by a screen reader, or because of some other assistive technology. Colors and font sizes can also be configured and they've been configurable since at least Windows 3.1 — and that is exposed to apps.

Again, I don't see how the things you specified can't be built into existing win32 APIs and why anything needs to be designed from the ground up to support them.

Your point about “apps don’t need to be made aware” is precisely the reason accessibility is part of the system UI framework.

Accessibility is also not something that is just a binary. You may be slightly short sighted and need larger text, you might need an OS specified colour palette that overrides the apps rendering. There’s just so many levels of nuance here. It’s not just “apps can configure a palette”, it’s that they need to work across the system

If you have the time, I really suggest watching the Apple developer videos on accessibility to see why it’s not just as simple as you put it. Microsoft do a lot of great work for accessibility too , they just don’t have much content up to delve into it.

As to why it has to be developed from the ground up, it doesn’t, but it needs to be at the foundation regardless. Apple for example didn’t redo their UI for accessibility, however Microsoft take a more “we won’t touch existing stuff in case we break it” approach to their core libs.

Also , again, I’d point out that you’re purposefully trying to trivialize something you don’t use.

> It’s not just “apps can configure a palette”, it’s that they need to work across the system

There is a system-provided color palette. I don't know where this UI is in modern Windows, but in versions where you could enable the "classic" theme, you could still configure these colors. They are, of course, exposed to apps, and apps are expected to use them to draw their controls. That, as well as theme elements since XP.

> Microsoft take a more “we won’t touch existing stuff in case we break it” approach to their core libs.

Making sure you don't break existing functionality is called regression testing. I'm sure Microsoft already does a lot of it for each release.

And actually it's not quite that. The transition from 9x to NT involved swapping an entire kernel from underneath apps. Most apps didn't notice it. In fact, the backwards compatibility is maintained so well that I can run apps from the 90s — built for, and only tested on, the old DOS-based Windows versions — on my modern ARM Mac, in a VM, through an x86 -> ARM translation layer.

> There's no need to visually redesign anything to introduce accessibility.

People with motion sickness (reduced animation), the deaf (captions!), and the colorblind would beg to differ

> Accessibility includes interaction design, zoom ability, audio commands, action link ups, alternate rendering modes, alternate motion modes, hooks for assistive devices to interact with the system. It goes far deeper into the system than just labels for a screen reader.

I wonder where the current status quo lies in regards to both desktop computing and web applications/sites. Which OSes and which GUI frameworks for those are the best or worst, how do they compare? How have they evolved over time? Which web frameworks/libraries give one the best starting point to iterate upon, say, component libraries and how well they integrate with something like React/Angular/Vue?

Sadly I'm not knowledgeable enough at the moment to answer all of those in detail myself, but there are at least some tools for web development.

  For example, this seems to have helpful output: https://accessibilitytest.org 
  There was also this one, albeit a bit more limited: https://www.accessibilitychecker.org
  I also found this, but it seemed straight up broken because it couldn't reach my site: https://wave.webaim.org/
  From what I can tell, there are many tools like this: https://www.w3.org/WAI/ER/tools/

And yet, while we talk about accessibility occasionally, we don't talk about how good of a starting point certain component frameworks (e.g. Bootstrap vs PrimeFaces/PrimeNG/PrimeVue, Ant Design, ...) provide us with, or how easy it is to setup build toolchains for automated testing and reporting of warnings.

As for OS related things, I guess seeing how well Qt, GTK and other solutions support the OS functionality and what that functionality even is is probably a whole topic in of itself.

> Which OSes and which GUI frameworks for those are the best or worst, how do they compare?

Hands down macOS/iOS are the leaders here with Cocoa/SwiftUI/UIKit etc (ultimately basically the same). The OS also has many hooks to allow third party frameworks to tie in to the accessibility.

Windows is second in my opinion. Microsoft does some good work here but it’s not as extensive in terms of integrations and pervasiveness due to how varied their ecosystem is now. They do however do excellent work on the gaming side with their accessibility controllers.

In terms of UI frameworks, Qt is decent but not great . Electron actually does well here because it can piggy back off the work done for web browsers. Stuff like Imgui etc rank at the bottom because they don’t expose the tree to the OS in a meaningful way.

I can’t speak to web frameworks. In theory it shouldn’t matter as long as the components are good. Many node frameworks try and install a11y as a package to encourage better accessibility.

> Windows, Electron

Gray on gray, Teams. Accessible like a hammer: everything looks like nails.

Irrelevant. You can make bad apps in any framework and bad accessibility choices as well. That’s not a reflection of the framework or tool itself

I switched from windows to macOS, which I’ve been using as my daily driver for the last year or so. Using the touchpad (or maybe the Magic Mouse) is basically a requirement to use “vanilla” macOS. Yes, you can install additional programs to help with window management, etc., but in my experience macOS is absolutely horrible when it comes to accessibility, from this standpoint. Maybe it’s better for colors, TTS, etc.?

Did you enable Full Keyboard Access and learn how to use it?

I’ll check it out. But this seems to approach accessibility as a feature to be turned on or off. Most of what it enables, based on Apple docs, is not just enabled in Windows and many Linux window managers I’ve used, but it’s something that developers actively utilize.

That's not where macOS came from. For Windows and Linux, "in the beginning was the command line" but not for Macs.

There's plenty one can do in macOS and its native applications with a keyboard by default, those that need more can enable "Use keyboard navigation to move focus between controls." Those that need even more enable Full Keyboard Access. These settings aren't on be default because Apple has decided they'd just get in the way and/or confuse people who use the keyboard but rely on it less.

In Safari specifically, by default pressing Tab doesn't focus links as it does in every other browser because most people use a cursor to activate links, not the keyboard. There also tend to be a lot more links than what Tab does focus, form inputs.

Macs try to have just enough accessibility features enabled by default that anyone who needs more can get to the setting to turn it on. Something I just learned Macs have that other OS/hardware doesn't is audible feedback for the blind to login when a Mac is turned on while full disk encryption is enabled.

I'm not claiming Apple gets everything right or that their approach is the best, I'm just trying to describe the basics of what's there and the outlook driving the choices.

I’m not sure what walls you might have been hitting but macOS is completely useable with speech direction. I had to quite recently add better accessibility support to an app I worked on and I was basically navigating the entire system with voice control and keyboard hotkeys.

Voice control in particular is really handy with the number and grid overlays for providing commands.

Thanks for those links. I found a few minor items in my website that I was able to easily address.

> it seemed straight up broken because it couldn't reach my site: https://wave.webaim.org/

It worked for me, it found lots of color contrast problems (white-on-light purple has low contrast). https://wave.webaim.org/report#/https://kronis.dev/

WAVE is also available as a browser extension.

Accessibility checkers can be helpful, particularly for catching basic errors before they ship. The large majority of accessibility problems a site can have cannot be identified by software, humans need to find them.

Current Bootstrap is not bad if you read and follow all of their advice. I'm not claiming there are no problems lurking amongst their offerings.

If you search for "name-of-thing accessibility" and don't find extensive details about accessibility in the thing's own documentation, it probably does a poor job. A framework can't prevent developers from making mistakes.

"The large majority of accessibility problems a site can have cannot be identified by software"

Bold statement. I used to work in exactly that area and the reality is humans often simply don't bother finding many of the accessibility issues that automated tools can and do find. Even if such a tool isn't able to accurately pinpoint every possible issue, and inevitably gives a number of false positives (the classic being expecting everything to have ALT text, even when images are essentially decorative and don't provide information to the user), the use of it at least provides a starting point for humans to be able to realistically find the most serious issues and ensure they're addressed.

However I would never claim that good accessibility support requires significantly more (e.g. >2x) resources, and certainly not at the OS level. In fact, you typically get better accessibility if you use the built-in OS (or browser) provided controls, which are less resource intensive than the fancy custom ones app seems to like using these days (even MS's own apps are heavy on custom-controls for everything).

I currently work in this area (web accessibility) and am just repeating what is commonly understood. When considering what WCAG criteria cover (which is not even everything that could pose a barrier to people with disabilities), most failures to meet the criteria cannot be identified by software alone.

For example, the classic I would say is not whether an image needs an alt attribute or not but whether an image's alt attribute value is a meaningful equivalent to the image in the context where it appears.

I'm not sure what kind of "resources" you're referring to. If you mean computing resources (CPU, RAM, etc.) standard, contemporary computers do seem to have enough for current assistive technologies, one doesn't need to buy a higher end computer to run them. If you mean OS resources for supplying assistive technologies and accessibility APIs, mainstream OS's are decent but specifically for screen readers there's a lot of room for improvement.

Reply on news.ycombinator.com