Re: Survey about digital accessibility evaluation and monitoring practices

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!