undefined | Better HN

0 pointsmiki1232114y ago0 comments

This argument has been brought up in the accessibility community multiple times, and it's not as straightforward as you might believe.

The problem with accessibility-focused frontends is that they lack in features. There's a much smaller number of users able to detect bugs and a much smaller number of developers willing to fix them and add new features whenever they appear in the mainstream app. This works pretty well for i.e. accessibility-first Twitter clients, but it probably wouldn't for your local utility company that serves ten or so blind customers, none of whom are programmers.

0 comments

5 comments · 2 top-level

csmpltn4y ago· 3 in thread

> "The problem with accessibility-focused frontends is that they lack in features."

Isn't that a consequence of building different tools that fit people with different situations? We do exactly this with physical tools and constructions: we build a wheelchair-friendly ramp alongside a traditional stairway. It's going to be a trade-off either way, right?

If we "choose" (I fully understand this is not an actual choice done by anybody) to stick to tools which try to auto-magically translate visual-first frontends into accessible frontends - we must accept that there will be things that mess with that translation process and cause it to fail. It's unrealistic to expect a translation that works 100% of the time, reliably. Sometimes it's a minor technicality that can be worked around - but other times it's because data presented visually in a certain way, can't always be translated to something else (ie. a heatmap, a 3D multiplayer game, etc). How do we make the Mona Lisa accessible to a blind person? On that same strength - should TUIs not be allowed to have progress bars or other visual elements?

miki123211OP4y ago

The solution here is to augment our tools with the information a screen reader needs.

To follow your example, we don't build separate bank branches for wheelchair users, we just extend existing branches with ramps, elevators and anything else they might need.

We already do this with other kinds of user interfaces. For example, web pages can be annotated with ARIA attributes, which don't influence how a page looks, but tell the screen reader that something is a checkbox which is currently unchecked. This is only required if you don't use the native HTML checkbox control, of course. Other platforms have their own ways of doing this, see iAccessible and UIA on Windows, ATSPI on Linux and AXElement on the Mac, for example.

Terminals were never meant for use cases like this, look at how hacky tty control codes are. If not for the fact that they're basically a bunch of ugly cludges that somehow work, there would probably be an aPI for that too. For now, though, we have to live with what we have.

csmpltn4y ago

> "The solution here is to augment our tools with the information a screen reader needs."

So we are in agreement that there should be different interfaces that suit each experience, we just disagree on the exact implementation details. I submit it's best to build entirely seperate experiences, but you submit it's enough to take the graphical-first experience and annotate it enough so that a screen-reader can generate an equivalent experience on the fly (using different kinds of annotation technologies). My response to this is:

1. Annotations and metadata (ARIA-labels, et-al) make it easier for the screen-reader to display relevant information in an accessible manner - but they create an unnecessary coupling between the visual-first frontend and the accessible frontend, when in reality they are built for different kinds of users.

2. Annotations are a decent starting point, but they are NOT a substitute for building an "accessibility-first" experience because they are too limited. You can't annotate a graph, or a progress bar, for example. But you could've built an entirely seperate experience which conveys the same data a graph would, in an accessible manner (given the right tools and frameworks).

madeofpalk4y ago

On the other hand if we know something will break one use case totally, to provide marginal utility in another, then it's probably not a good trade off.

jdavis7034y ago

> but it probably wouldn't for your local utility company that serves ten or so blind customers, none of whom are programmers.

This is exactly why section 508 and ADA liability rules exist. If they don’t know how to make their programs accessible, a very expensive lawsuit will show them how. Also, why would a small utility be writing their own software? Shouldn’t they be using COTS?

j / k navigate · click thread line to collapse