RE: Survey about digital accessibility evaluation and monitoring practices

The trouble with any argument based on WCAG being the standard, is that according to WCAG’s definition of “accessibility supported”, CSS, JavaScript and some other web technologies are accessibility supported. That means that website authors are able to rely on these technologies when claiming WCAG conformance.

They are supposed to state this reliance in their accessibility conformance statement, although few organisations do because the commonly-used VPAT does not require it (which I think it should). It refers to “accessibility-supported ways of using technology” but does not require that they are listed. The W3C example conformance statement does require it.

The result is that a website can legitimately claim conformance with WCAG 2.1, even at level AAA, yet it may not work with Lynx and other user agents that do not support CSS and/or JavaScript.

This is very different from WCAG 1.0, which required that websites were accessible with CSS or JavaScript turned off.

Whilst I am no fan of Google, it’s not just them. A vast number of websites are fully or partially unusable with CSS or JavaScript turned off or not supported by someone’s user agent. The concept of progressive enhancement seems to have been forgotten.

In the UK, the GDS Service Standard states that all central government department websites must work without CSS, JavaScript or images. When we point this out to developers, their response is usually incredulity that anyone would think it’s possible, let alone mandate it. But of course it’s entirely possible in most cases.

Steve Green
Managing Director
Test Partners Ltd


From: S <Starry_sky@live.com>
Sent: Saturday, May 6, 2023 7:54 PM
To: Carlos Duarte <caduarte@campus.ul.pt>; WAI Interest Group discussion list <w3c-wai-ig@w3.org>
Subject: 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 DuarteLASIGE, Faculdade de Ciências, Universidade de Lisboa
caduarte@campus.ul.pt<mailto: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><mailto: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!