Re: Comprehensive WCAG conformance leads to accessibility for all irrespective of the technology used-any statement to prove this legally?

 Here's the too long, didn't read version of my post:  I disagree with
Steve Repsher on a number of points about accessibility support and the
implications this phrase has on the participants who help define accessible
user experiences.  In my opinion testing with assistive technology is
fantastic advice that I recommend to all testers, but it isn't required to
measure conformance under the Web Content Accessibility Guidelines.

Hi Steve Repsher,

That's an interesting opinion you have on the meaning and intent of
"accessibility supported." I always thought that at least part of the
meaning of "accessibility support" had to do with rules that the
Accessibility Guidelines Working Group had to follow when they proposed new
Success Criteria.  I thought that it wasn't OK for the Working Group to
establish a new Success Criterion if there was no "accessibility support"
for the new rule at the time. In other words, I thought that at least part
of the meaning of "accessibility support" in WCAG world is to not make
content authors jump through hoops to follow a rule if there is no
accessibility support for the rule out in the wilds of the Internet that
will yield real benefits to real users with disabilities.

Think about SC 1.3.5 Identify Input Purpose and SC 1.3.6 Identify Purpose.
Both of those WCAG 2.1 additions require the use of content implentation
techniques that should yield a user benefit to people with disabilities
when parsed through required assistive technology.  At the time of WCAG 2.1
finalization, were there ways that assistive technology testing for these
two rules would tell testers, "Yes this site complies with the rules and
following the new rules yields an intended user benefit that is obvious?"

I know you were on the Working Group when these rules were crafted.  So was
I.  How did you personally consider "accessibility support" for these two
Success Criteria when vetting them for inclusion in the final WCAG 2.1
standard?  Was there accessibility support for Identify Input Purpose and
Identify Purpose when the rules were finalized?

I also thought that "accessibility support," as documented in the Understanding
WCAG 2.1 document
<https://www.w3.org/WAI/WCAG21/Understanding/conformance#accessibility-support>
was a two-way street.  Content authors must do their parts, and software
manufactures need to their parts, as well, to be have "accessibility
support."  Here's an excerpt from that Understanding WCAG 2.1 document:

"When new technologies are introduced, two things must happen in order for
people using assistive technologies to be able to access them. First, the
technologies must be designed in a way that user agents including assistive
technologies could access all the information they need to present the
content to the user. Secondly, the user agents and assistive technologies
may need to be redesigned or modified to be able to actually work with
these new technologies.

"*Accessibility Supported*" means that both of these have been done and
that the technology will work with user agents and assistive technologies"

What evidence do we have that user agent and assistive technology
manufacturers have been doing their parts to ensure accessibility support?
Seems like placing all of the burdens of access on content authors, and
none on the standards bodies, wares manufacturers or even users is the way
things have gone in the past.  How's that worked out for everyone?  If you
are a software manufacturer or standards body, I would imagine it feels
pretty good.  For content authors and users with disabilities, I don't
think the current system works nearly as well as it could.

Lots of governments have adopted WCAG, which is often mistaken by casual
observers as the Web Content Author Guidelines, into law.   How many
governments have adopted regulations for software/hardware manufacturers,
or even standards bodies, when it comes to codifying support for digital
access?  Why not?  Are these governments aware of the lopsided burden
content authors and owners are required to bear under the WCAG rules?  If
they were aware, would they have adopted WCAG into law so readily?

I think, as an accessibility tester, you are making a big mistake if you
don't test your content with assistive technology.  I do not, however,
believe that testing with assistive technology is required.  I believe that
content authors should be able to create content and code to a standard and
be able to claim conformance with accesibility guidelines.  I also believe
that wares manufacturers and standards bodies should also be required to
follow regularly updated standards in creating their products to achieve
optimal results.  Users, you are going to have do your parts, too.  I know
that I'm not alone in my understanding.

Brooks Newton

On Fri, Sep 16, 2022 at 3:24 AM Steve Repsher <steverep@gmail.com> wrote:

> Hi Steve,
>
> you stated:
>
> However, WCAG does not require websites to be tested using assistive
>> technologies and it does not require the website to work correctly with
>> them.
>>
>
> This is not correct.  In order to claim conformance to WCAG, the website
> must be accessibility supported (see section 5.2.4 of WCAG
> <https://www.w3.org/TR/WCAG21/#cc4>).  From the normative definition of
> accessibility supported, the first requirement is:
>
> 1. The way that the Web content technology is used must be supported by
>> users' assistive technology (AT). This means that the way that the
>> technology is used has been tested for interoperability with users'
>> assistive technology in the human language(s) of the content,
>>
>
> So, in short, you cannot claim conformance to WCAG if your website doesn't
> work with available screen readers.
>
> The 2nd requirement goes on to basically try to explain which browsers and
> screen readers the website needs to work with, which depends on
> availability.  So, for example, if all of the users of a particular
> internal website only had access to JAWS, then it must work with JAWS or
> you would not be able to claim conformance.  Or, for example, if JAWS were
> not distributed anywhere in India so everyone used NVDA, then you should
> test with NVDA.
>
> Where the WCAG gets vague is when asking questions about how much
> accessibility support is required, but it certainly does require support by
> assistive technologies.
>
> Steve
>
>
>
> On Wed, Sep 14, 2022 at 7:37 PM Steve Green <
> steve.green@testpartners.co.uk> wrote:
>
>> I can’t address some of your questions, and unfortunately the answer I
>> can give doesn’t support your case.. Even though WCAG conformance is
>> technology independent, comprehensive conformance to WCAG does not
>> guarantee that you won’t get different results with different assistive
>> technologies. In the case of screen readers, the behaviour is always
>> different.
>>
>>
>>
>> WCAG requires that websites expose information including the roles,
>> states and properties of elements, such that assistive technologies can
>> interact with the website correctly and convey the correct information to
>> the user. However, WCAG does not require websites to be tested using
>> assistive technologies and it does not require the website to work
>> correctly with them.
>>
>>
>>
>> Assistive technology behaviour is covered by the User Agent Accessibility
>> Guidelines (UAAG) and is the responsibility of the assistive technology
>> vendor. In principle, if a website is WCAG conformant and an assistive
>> technology is UAAG conformant, then the website should work correctly with
>> that assistive technology. However, the UAAG do not specify exactly how
>> screen readers should behave under all circumstances.
>>
>>
>>
>> In practice, no two screen readers behave the same. There are some
>> intentional differences, such as Voiceover not having a “virtual cursor”
>> mode, which JAWS and NVDA do have. There will also be unintentional
>> differences because the vendors don’t copy each other (too much).
>> Inevitably, screen readers will have bugs, so they do not work as the
>> vendor intended and perhaps genuinely believes they do.
>>
>>
>>
>> Furthermore, the HTML, CSS, ARIA and JavaScript specifications are under
>> continuous development. No screen reader supports every aspect of them.
>> Many aspects are widely supported, but support for new aspects is
>> inevitably variable, and even some old aspects are not supported by all
>> screen readers.
>>
>>
>>
>> Perhaps the biggest difference between JAWS and NVDA is the use of
>> heuristics. Screen reader vendors know that only a tiny percentage of
>> websites are coded properly, so to improve the user experience, JAWS uses
>> heuristics to guess what the author really meant. For instance, if a
>> textbox is not labelled, JAWS assumes that the text immediately before it
>> in the DOM is its label, which will be correct most of the time (but not
>> always). By contrast, NVDA does not appear to use any heuristics, so in
>> this case it would announce the textbox as being unlabelled.
>>
>>
>>
>> As a rule, NVDA gives a more accurate user experience, while JAWS gives a
>> better user experience because it compensates for some aspects of bad
>> coding. It is therefore curious that the tax submission portal would work
>> better with NVDA. I can’t imagine what weird coding Infosys have done that
>> results in that. Can you give me access to the portal?
>>
>>
>>
>> Steve Green
>>
>> Managing Director
>>
>> Test Partners Ltd
>>
>>
>>
>>
>>
>> *From:* Amar Jain <amarjain@amarjain.com>
>> *Sent:* 14 September 2022 06:38
>> *To:* w3c-wai-ig@w3.org
>> *Subject:* Comprehensive WCAG conformance leads to accessibility for all
>> irrespective of the technology used-any statement to prove this legally?
>>
>>
>>
>> Dear all,
>>
>>
>>
>> By way of a quick introduction, I am Amar Jain, a corporate lawyer and a
>> Certified Professional in Web Accessibility based out of India.
>>
>>
>>
>> We have a case going on for inaccessibility of our tax submission portal.
>> The vendor is Infosys, and the problem is that only those issues that we
>> are highlighting are getting resolved and comprehensive audit is not being
>> done due to commercial reasons.
>>
>>
>>
>> Further, there seems to be hard coding for NVDA, as the portal is
>> reasonably functional with NVDA and not with Jaws. The lack of audit is
>> also leaving behind persons with other disabilities.
>>
>>
>>
>> The argument of the vendor is that it is because of the architecture of
>> the portal which is why NVDA will be the only screen reader which should be
>> used for maximum functionality. Second argument is more legal in nature,
>> which is to say that current Indian standards only restrict testing with
>> NVDA which we can work around.
>>
>>
>>
>> We need to prove to the Court that a comprehensive WCAG conformance is
>> technology independent and irrespective of the technology that people use,
>> a comprehensive conformance will ensure widest accessibility possible.
>>
>>
>>
>> Is there any document which backs-up this statement and is there any
>> precedent where comprehensive audit has been asked by way of a court order?
>>
>>
>>
>> In nutshell, I need to convince the court that a comprehensive audit is
>> the only way to go, and a comprehensive conformance to WCAG will not
>> produce different results with different technologies in terms of
>> accessibility.
>>
>>
>>
>> Your valuable inputs will be greatly appreciated before September 22.
>>
>>
>>
>> Regards,
>>
>> Amar Jain
>>
>