Re: Survey about digital accessibility evaluation and monitoring practices

We agree with some of Guy's points but also have to dispute a few. Last 
year, the DOJ has issued guidance that websites, etc. must be accessible 
and they pointed to wcag as the standard so that long-standing argument 
about suggestion vs requirement no longer applies.

Any *reputable *technology person or company would test the digital 
product to make sure it works across multiple devices, operating 
systems, key browsers, and with assistive technology.  The device 
manufacturer is responsible for the hardware and to function with the 
operating system installed but not for how the digital product works.  
It is the creator of the digital asset that is responsible to make sure 
it works or inform people if there are limits like browser version.  In 
this case, Google is responsible for the accessibility of its form.

But Google is not about providing products especially accessible ones.  
IMO Google's business model is finding ways to gather and sell 
information about you.  Often Google "products" are limited or 
inoperable when your system blocks or limits its ability to gather your 
data.  Two people can have the same device, operating system, browser 
version, etc. but the one that limits or blocks javascript, cookies, 
beacons, trackers, etc. may have limited or no access to the Google 
product.  This is by design.

On 5/5/2023 1:26 PM, Carlos Duarte wrote:
> Guy, thanks for the input. Without taking anything away from it, I 
> would like to quickly comment on the form, since I was the one sharing 
> it. After Karen's email I tried it using Lynx (on MacOS). As you are 
> probably aware, the form is hosted on Google Forms. I was unaware (my 
> fault) that navigation through the form fields in Google Forms is 
> handled by JavaScript. The issue is that Lynx does not support 
> JavaScript, making the from impossible to operate.
>
>
>  
> *Carlos Duarte*LASIGE, Faculdade de Ciências, Universidade de Lisboa
> caduarte@campus.ul.pt
> https://www.di.fc.ul.pt/~cad/
> Twitter <https://twitter.com/carlosapaduarte>
>
> On May 5 2023, at 6:07 pm, Guy Hickling <guy.hickling@gmail.com> wrote:
>
>     Karen, I think the issues you are experiencing, and the reasons
>     why, have to be considered in the context of how the WCAG is
>     formulated and how technology devices work. The WCAG Guidelines
>     you quote are just that - they are general guidelines, not hard
>     rules. So they identify principles we are trying to follow but,
>     within the WCAG document itself, they are really little more than
>     subheadings. I.e. they classify what follows - the Success
>     Criteria listed under them.
>
>     So it is not the responsibility of web developers to exhaustively
>     ensure the principle stated in Guildeline 4.1 "Maximize
>     compatibility with current and future user agents, including
>     assistive technologies" is adhered to at all times. The huge range
>     of devices and programs of all kinds, operating in the internet
>     space, makes that fundamentally impossible - it would take a
>     developer's entire lifetime to check just one website works with
>     everything, and their development work would stop!
>
>     The way it works is that developers are expected to follow the
>     Success Criteria (SC) listed under each Guideline. So under
>     Guideline 4.1, for instance, we have Success Criteria 4.1.1,
>     4.1.2, and 4.1.3; these are 3 "rules" (if I may call them that)
>     that all developers should follow when creating web content.
>
>     Developers should always read, know, and follow the HTML and ARIA
>     specifications (among other things). SC4.1.1 mentions several
>     aspects of this that are particularly relevant to HTML, and to
>     accessibility of different people, and that can be checked by any
>     accessibility tester. 4.1.1 says "... elements have complete start
>     and end tags, elements are nested according to their
>     specifications, elements do not contain duplicate attributes, and
>     any IDs are unique..." So developers should do that, and testers
>     can check they have done so. (NB: the fact that 4.1.1 is under
>     notice of possible removal is beside the point, so don't anyone
>     bring that in to the discussion please. It's there now, and
>     developers should be following it now.)
>
>     At that point, however, the developer's responsibility, in this
>     particular respect of 4.1.1, ends, and another responsibility
>     comes into play. The manufacturers of browsers, assistive
>     technology also have a responsibility. They also must follow the
>     HTML and ARIA specs when they create the particular devices they
>     want to sell or distribute, and they also have an equivalent of
>     the WCAG they should follow, the UAAG. And there is a substantial
>     area of "good practice" as well, that they and developers should
>     follow, that is not always specified (yet) in either the HTML spec
>     or the WCAG.
>
>     When both web developers creating websites and apps, and
>     manufacturers of software such as web browsers, both follow the
>     specs and the WCAG Success Criteria, we have the best chance of a
>     website or app being accessible to most people, including disabled
>     people using assistive devices. But it is a two-pronged requirement.
>
>     So others who posted in this thread checked the input form you are
>     querying, and they found it works, for them - probably using MS
>     Windows PCs (I guess). That therefore suggests the problem is in
>     the particular devices you are using - but the responsibility for
>     that is on the manufacturers of your devices, not on the developer
>     who created the input form! This is why we were asking earlier
>     what devices you are using.
>
>     So, if you tell us which operating system you are using (though
>     someone seems to have worked out its Linux), and the web browser
>     you are using (the same person thinks it might be Lynx, is that
>     correct?), exactly what the problem was, and which page or pages
>     of the form you found the problems on, and which form components,
>     someone with a Linux PC might be able to test the input form, in
>     that particular browser, and see what the trouble is and, maybe,
>     what's causing it. (The only problem is that most people don't
>     have access to a Linux PC, it is not that common an operating
>     system. And they might not have the browser you are using; so I
>     can't guarantee you might get help even then!)
>
>     But there isn't any way the developers who create that input form
>     can guarantee it will work on all technology - that's not an
>     exclusion of you, its faults in the technology suppliers! In the
>     Windows world, the JAWS, NVDA and VoiceOver screen readers all try
>     to follow the specs, but they all have bugs in them where they
>     don't quite make it. Sooner or later they usually fix them.
>
>     I hope this explains why the form hasn't worked for you in this
>     case, on the software tools you are using. Having said that, the
>     survey form in question seems pretty basic, though I have not
>     looked all through it or in any detail. So I would be worried if
>     an ordinary web browser, on Linux or anywhere else, is not able to
>     handle it properly!
>
> Sent from Mailspring