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 mailto:blind-sysadmins@lists.hodgsonfamily.org> Reply-To: Mailing list for blind system administrators 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" mailto:blind-sysadmins@lists.hodgsonfamily.org> Cc: Jason White 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

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 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 mailto:blind-sysadmins@lists.hodgsonfamily.org> Reply-To: Mailing list for blind system administrators 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" mailto:blind-sysadmins@lists.hodgsonfamily.org> Cc: Jason White 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 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

I think this is a well informed summary. I can clarify, however, that no one has a veto with respect to W3C specifications such as the Web Content Accessibility Guidelines. There is a process for resolving formal objections raised by participants, but these can be overcome if judged not to be well founded.

On Jul 1, 2023, at 02:45, mhysnm1964@gmail.com wrote:

The web content accessibility guidelines is the foundations for accessibility and used by all regulations. The standards apply to mobile, desktop native apps, web, documents, etc. Section 508, the EU standards and other countries use this standards as their means of identifying if a product is compliant to accessibility (A11y).

Are the standards complete or is their grey areas. Yes. Some of the standards are left up to interpretation. For example what is a meaningful image with alt text. This can be a interesting conversations with Accessibility SMEs.

The issue with all companies who create apps, web sites, etc. They do not treat accessibility with the same degree of importance as other requirements for building products and services. For example, only one company in the world I am aware of has a strict go to market for WCAG Level A. If there is any level A defects then the product doesn't launch with the feature turn on. Wouldn't this be nice if all companies did this. There are many companies who are including accessibility into the products. What I have seen from these companies is the quality of testing or implementation leaves a lot to desire. Either the UX is a hack for specific assistive tech like screen readers, introducing features specific for screen readers which isn't always a good experience or the general UX is far to complex to use.

The other issue if an accessibility defects are known by a company. The length of time they resolve it is normally way longer than non-accessibility defects. This is because they do not give accessibility the same treatment as normal defects. Even if they say they do.

Through the Rumer mill, I have heard the large tech companies and companies who create browser engines have veto rights over how the new standards related to Web content Accessibility Guidelines (WCAG) are created. If this is true, then I feel that is an conflict of interest. AS these companies will do what is best for themselves disguised in doing the best for their customers. The other people who are involved with creating the standards are normally from the big accessibility companies.

Finally the disability community themselves are our own worse enemies. Speaking to a range of companies who are very interested in making accessibility truly a change maker in their products. Their biggest feedback is we do not get enough people with disabilities raising support request or complaining. The number of times I see a general request on a blind mailer for a specific product or general mailers where people are asking the community how to resolve a problem which would be better suited to go to the vendor is quite high. We need to do this to show the vendors there is a true market out there who are buying their product and have a disability. This all links into return of investment. As companies don't believe there is any ROI and will not invest into accessibility. Basic business model.

Sean

-----Original Message----- From: Samuel Barnes Sent: Thursday, June 22, 2023 9:54 AM To: Mailing list for blind system administrators Subject: [Blind-sysadmins] Re: The scale of software accessibility

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 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 mailto:blind-sysadmins@lists.hodgsonfamily.org> Reply-To: Mailing list for blind system administrators 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" mailto:blind-sysadmins@lists.hodgsonfamily.org> Cc: Jason White 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 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

_______________________________________________ Blind-sysadmins mailing list -- blind-sysadmins@lists.hodgsonfamily.org To unsubscribe send an email to 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