It wasn't really meant to be serious, just a way to blow off some steam. I've run into a lot of closed doors in terms of employment where people questioned how much it would cost to make their workflow accessible or expressed doubt that I could do the job. It would sure be nice if I could just assume everything was usable out of the box but that just isn't the case as everyone reading this probably already knows. So I got to thinking about to what degree a program is accessible, and how that accessibility is achieved. I didn't even think about the documentation not being accessible. That's a good point. On Sun, Jun 18, 2023 at 6:34 PM Jackie McBride <abletec@gmail.com> wrote:
If you're going to have some sort of system to grade an app on accessibility,then there needs to be criteria on which it's based & quantification as to how well the app did or did not meet those criteria.
IMO, accessibility is not a 1-size-fits-all proposition. An app can technically be accessible, but the U X sux. Or, as Ryan points out, the lack of documentation, whether accessible or not, can make an app unusable.
& it should also be based more on just usability w/screenreaders & keyboards.
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
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
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
On 6/18/23, Ryan Shugart <rshugart@ryanshugart.com> wrote: the like list.
On 5/6/23 22:00, Samuel Barnes wrote:
Here's something a little different. I've been kicking around the idea
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
of 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>
_______________________________________________ Blind-sysadmins mailing list -- blind-sysadmins@lists.hodgsonfamily.org To unsubscribe send an email to blind-sysadmins-leave@lists.hodgsonfamily.org
-- Jackie McBride Author 36: Last Hours of a Life Be a hero. Fight Scams. Learn how at www.scam911.org Also check out brightstarsweb.com & mysitesbeenhacked.com _______________________________________________ Blind-sysadmins mailing list -- blind-sysadmins@lists.hodgsonfamily.org To unsubscribe send an email to blind-sysadmins-leave@lists.hodgsonfamily.org