Hi: This is an interesting thing to think about, one possibly small but I think important distinction to make here is a difference between software accessibility and content accessibility. For example, in case 0 mentioned below, the Kindle app is perfectly accessible, but some authors chose, for whatever reason, to deliberately disable accessibility features. I think this is more common with content than actual software, although I have heard of very rare cases of authors choosing to disable accessibility APIs in their software for performance or security or other reasons. Some other things to think about, what if an app itself is perfectly accessible, but the documentation that comes with said app is very inaccessible, so you can use the app but you have no clue how to actually use it properly? I encountered this a lot back in my sysadmin days, even if the admin console for the app I needed to administer was perfectly accessible, the documentation was just a bunch of cut and paste screen shots, which was equally frustrating. Or, in one case, the developer acknowledged that the GUI version of their app was completely inaccessible, and pointed me to a CLI version that was accessible, but the CLI version had no documentation describing how to use it, so I had to eventually give up even though the app was accessible, I didn't have time to try different commands and see what happened while my sighted peers could just read docs and get their jobs done. Just some interesting perspectives when thinking through a scale like this, I like the idea but think there's a lot of greyness here too. Ryan -----Original Message----- From: Jason White via Blind-sysadmins <blind-sysadmins@lists.hodgsonfamily.org <mailto:blind-sysadmins@lists.hodgsonfamily.org>> Reply-To: Mailing list for blind system administrators <blind-sysadmins@lists.hodgsonfamily.org <mailto:blind-sysadmins@lists.hodgsonfamily.org>> Date: Tuesday, June 6, 2023 at 6:18 AM To: "blind-sysadmins@lists.hodgsonfamily.org <mailto:blind-sysadmins@lists.hodgsonfamily.org>" <blind-sysadmins@lists.hodgsonfamily.org <mailto:blind-sysadmins@lists.hodgsonfamily.org>> Cc: Jason White <jason@jasonjgw.net <mailto:jason@jasonjgw.net>> Subject: [Blind-sysadmins] Re: The scale of software accessibility This is interesting, and I welcome some of the distinctions drawn. As a user and in administering my own systems, I work with terminal-based and command line tools frequently. They are "accidentally accessible" to screen readers, in that the developers have typically made no effort to support accessibility, but nor is such an effort usually needed. That is, they are accessible simply in virtue of the implementation technologies used. I suspect some graphical applications that use only standard widgets and use them correctly could achieve the same result, as could Web pages that only use standard form controls correctly (with labels etc.). So perhaps there should be an additional category to cover such cases. I'll gladly take this discussion elsewhere if it's off-topic for this list. On 5/6/23 22:00, Samuel Barnes wrote:
Here's something a little different. I've been kicking around the idea of a numeric score to grade the accessibility of software. It still needs work, but this is what I have so far:
0. Deliberately inaccessible: The developer purposely hinders the program's accessibility. Example: Some books on Amazon kindle will specifically announce their incompatibility with screen readers. (I'm guessing this is fallout from the Authors' Guild complaining about the Kindle's use of TTS supposedly cutting into audio book sales).
1. Completely inaccessible. The program cannot be used by screen readers. Example: old Flash and Java apps.
2. Accidentally accessible. Some parts may be accessible thanks to the various software libraries or platform used, but the devs aren't deliberately trying to make the software accessible. Often this accessibility is only achievable through workarounds. Example: Navigating from comment to comment on Reddit requires you to jump from downvote button to downvote button.
3. Acknowledged inaccessibility. The devs know the software is inaccessible, and acknowledge it in some way by pointing to 3rd party workarounds or alternative software that is accessible. Example: VanDyke software (who makes SecureCRT) just has a page pointing to some 3rd party JAWS scripts.
4. Mostly accessible. The program is usable enough to rely on in a workflow, and the devs make an effort to keep things from breaking, but accessibility bugs aren't given the same level of care as other issues. Example: Microsoft Office.
5. Accessible. Every part of the user experience is accessible. The devs may even pay attention to little details like sound cues and button colors. But as above, sometimes issues arise and aren't dealt with as quickly as one would like. Example: some of Apple's first party apps.
6. Completely accessible. Not only is every part of the software accessible, but any bugs that hinder accessibility are treated with the same urgency as bugs that would hinder the software's usability for the general public. An update is never shipped unless accessibility has been confirmed. Example: I literally can't think of one.
So yeah, just a bit of fun. What do you think? _______________________________________________ Blind-sysadmins mailing list -- blind-sysadmins@lists.hodgsonfamily.org <mailto:blind-sysadmins@lists.hodgsonfamily.org> To unsubscribe send an email to blind-sysadmins-leave@lists.hodgsonfamily.org <mailto:blind-sysadmins-leave@lists.hodgsonfamily.org>
Blind-sysadmins mailing list -- blind-sysadmins@lists.hodgsonfamily.org <mailto:blind-sysadmins@lists.hodgsonfamily.org> To unsubscribe send an email to blind-sysadmins-leave@lists.hodgsonfamily.org <mailto:blind-sysadmins-leave@lists.hodgsonfamily.org>