I am happy to expand this complexity when it comes to user safety. Less willing (but always open!) for the sake of convenience.
Top-level
I am happy to expand this complexity when it comes to user safety. Less willing (but always open!) for the sake of convenience. 3 comments
@gaditb Good question! I don't think there is a clear line there at all. That's a very difficult judgement call to make. Like, supporting low-vision users is for me obviously accessibility, but then there are features that I think are about convenience where you could make an accessibility argument based on neuroatypicality. No good answers here, just judgement calls. @darius I haven't studied this formally but the general sense I've gotten is that "attempt to anticipate all accessibility needs ahead of time" is an anti-pattern. Most of what I've seen has emphasized, where possible, giving users the flexibility to set their own environments to be accessible, and putting effort to ensure the document or application doesn't break when changing -- and provides enough control points to change it in the first place -- in those ranges, rather than a discrete set of set paths. |
@darius Where do we draw the line between "convenience" and "accessibility"?
(I'm skeptical there is one.)