Re: Survey about digital accessibility evaluation and monitoring practices

Guy,
Thanks for your comment, but it seems to illustrate my point.
For better or worse, and likely not intended, there can be a huge 
difference between what some of those involved with WCAG formulation 
believe  and outsiders.
I have for example come across, more than once, businesses claiming that 
their web presence is WCAG certified..usually followed by works for 
everyone!
Please know I realize those involved with WAI work very hard indeed. 
However, and this has been touched on before,  how WCAG gets  managed in 
many other arenas, that these are laws, that a single individual can 
represent the needs of millions, that they cannot really be understood 
anyway, so  said testing company  can say what they want...that one can 
tell an individual  what tools to use, even if unsafe for them, all still 
happens too.
Honestly? speaking personally, waI  needs a really good documentary made.
Something that shifts your work from the very very long and for many 
complex  ideas success chritera  guidelines and the like into human experiences 
and relatable stories.
Its frankly a shame, WCAG is well used in countless ways beyond the 
intention, and likely many using  it has no idea of your story, its actual 
goal, and how to implement much of these policies.
Access impacts the daily existence of well almost everyone, no matter what 
experience they embody physically.
What you consider  guidelines in context some consider avenues to work, 
banking, to a place along side others in their communities.
That might not have been your goal at the start, but your work is so 
pervasive now that it is certainly the reality for many.
best,
Karen



On Fri, 5 May 2023, Guy Hickling 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!
>

Received on Wednesday, 17 May 2023 20:58:30 UTC