[Blind-sysadmins] Re: The scale of software accessibility

1 Jul 2023


      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