Re: Survey about digital accessibility evaluation and monitoring practices

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/

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!