…k F109, add figures and mention "other" cognitive tests (#4832)

* rename "Authentication Approaches" to "Login forms" - the former
implies that this section will start to list approaches, when in fact it
simply talks about login forms
* tweak the language to better cover/differentiate user agents and
third-party password managers
* explicitly mention things that would not be acceptable - preventing
browser/password managers from automatically populating fields, *or*
stopping copy/paste
* remove the test step mention about pasting OR auto-filling in F109;
this failure technique is in fact orthogonal to what is being discussed
in #3550 - the point of this failure technique is about the format of
the entry, not about pasting versus auto-filling, but removing this
apparent ambiguity should help
* add illustrative images to F109 to make it clearer what the problem is
that the failure refers to
* add illustrative images to both 3.3.8 and 3.3.9 understanding
* add a new section to 3.3.8 understanding about other types of
cognitive tests (math test, logic test, etc)
https://deploy-preview-4832--wcag2.netlify.app/understanding/accessible-authentication-minimum#other-cognitive-tests

Closes #3550

Previews:

*
https://deploy-preview-4832--wcag2.netlify.app/understanding/accessible-authentication-minimum
*
https://deploy-preview-4832--wcag2.netlify.app/techniques/failures/f109
*
https://deploy-preview-4832--wcag2.netlify.app/understanding/accessible-authentication-enhanced

This PR looks to clarify the third advisory technique bullet for SC
1.3.6 Identify Purpose - aiming to close #2545

The previous text for the bullet just stated:
>Using aria-invalid and aria-required

This PR extends this text to mention that one could use the `required`
attribute _or_ those aria attributes to identify required fields and/or
those with validation errors. Thus, tying why the attributes are
mentioned to identifying the states of these fields.

I did not add this advisory technique to 1.3.5 Input Purpose, as was
mentioned in the comments for the original issue. IMO, I don't think
it's necessary to mention the concept of required in that SC. But, if
others in the backlog taskforce disagree, it'd be easy enough to add to
this Pr...


[Preview](https://deploy-preview-4663--wcag2.netlify.app/understanding/identify-purpose#techniques)

---------

Co-authored-by: Patrick H. Lauke <redux@splintered.co.uk>
Co-authored-by: Bruce Bailey <bruce@bailey4.us>
Co-authored-by: Adam Page <adam@adampage.net>

)

This fixes a bug in the logic added in #4170, which looked up errata for
terms using their auto-generated ID in the Understanding docs, rather
than by their explicit ID as defined in the `guidelines` folder. These
are sometimes but not always the same, so some lookups would fail.

…ces (#4817)

Closes #4444

Preview:
https://deploy-preview-4817--wcag2.netlify.app/understanding/pause-stop-hide
(last note before the "Benefits" section)

---------

Co-authored-by: Adam Page <adam@adampage.net>

)

While ideally we'd want to actually change the normative wording of the
SC (see #4952), if that fails for now,
this PR adds a note to 4.1.3 Status Messages understanding that
handwaves "when we say roles and properties, we also meant accessibility
API access". It also adds a new technique and working example
demonstrating the use of `ariaNotify`.

/cc @adampage @scottaohara @fstrr 

Previews:

*
https://deploy-preview-5079--wcag2.netlify.app/understanding/status-messages
(note at the end of "Intent")
* ARIA27
https://deploy-preview-5079--wcag2.netlify.app/techniques/aria/aria27
* working example
https://deploy-preview-5079--wcag2.netlify.app/working-examples/aria-notify-status-message/

---------

Co-authored-by: Adam Page <adam@adampage.net>
Co-authored-by: Bruce Bailey <bruce@bailey4.us>
Co-authored-by: Kenneth G. Franqueiro <kfranqueiro@users.noreply.github.com>

Ports over most of the ideas from #4316,
but extends/clarifies them further.

Expands on what "standard exit methods" are (and the fact that WCAG
doesn't actually normatively define these, that they're hardware/OS/UA
dependent, and that authors/auditors will need to use their judgement
here). Also reiterates that even if untrapping involves "non-standard"
methods, that's fine as long as users are informed how to do it (but
still needs to be using the keyboard).

Also cleans up the markup a bit.

Tweaks the modal dialog example (focusing on the focus trapping, rather
than the opposite - which parts of the page don't receive focus anymore)
and adds a new example for Rich Text Editors.

Supersedes #4316 (as that PR didn't allow for changes to be pushed to
it, including rebasing it to the latest main branch)

Preview:
https://deploy-preview-4726--wcag2.netlify.app/understanding/no-keyboard-trap

…#4814)

Whether or not a text alternative is visually/visibly presented to users
when CSS is disabled/unavailable is beyond the scope of 1.1.1. Rewording
the last failure check to make the original intention clearer.

x-ref #4660 (comment)

EDIT: after some further consideration, this PR also:

* changes the wording throughout away from "important information"
* retitle the technique
* in the tests, it adds the caveat that the information conveyed by the
image is only of interest if it is not already conveyed elsewhere on the
page
* make test step 2 positive rather than negative, and amend the expected
result, to make it more easily understandable

https://deploy-preview-4814--wcag2.netlify.app/techniques/failures/f3

---------

Co-authored-by: Adam Page <adam@adampage.net>
Co-authored-by: Bruce Bailey <bruce@bailey4.us>

This short "in passing" mention in a note about CSS background images
appears to introduce a whole new normative requirement by the backdoor,
in a technique note, which effectively fails sites that don't provide
both a background colour AND background image in their CSS, because
users MAY have changed their browser not to load images.

This is not covered anywhere else in WCAG, and in many other places WCAG
explicitly does NOT care about how users may have modified/changed their
browser settings. Not even 1.1.1 mentions the scenario as a particular
reason/concern. This note oversteps its remit.

EDIT: reworked this PR to only remove/amend the apparent normative
requirement to define BOTH a background image AND background colour -
replaced with a note about contrast testing. Further, this PR now
corrects the inaccurate section about inherited color/background
(background is not inherited - if not defined, an element has a
*transparent* background, so what counts is that at least one of the
ancestors of the element has a background

x-ref #4660 (comment)

preview:
https://deploy-preview-4823--wcag2.netlify.app/techniques/failures/f24

---------

Co-authored-by: Adam Page <adam@adampage.net>

…ive) (#5037)

single word is more common in the wild, and used more often in WCAG and
its documentation than the two-word variant

noticed as part of work on #4843

there is also a single instance in the normative definition for single
pointer. will file a separate editorial erratum PR for that (see
#5038)

Noticed as part of the work on #4832

This adds the "Figure X..." part to all figure captions in techniques
(this currently only happens in understanding pages)

Closes #5061

Preview example:
https://deploy-preview-5062--wcag2.netlify.app/techniques/failures/f69
(compare to https://www.w3.org/WAI/WCAG22/Techniques/failures/F69)

redo of #2899 - while the "black/white
colour blindness" part has since been fixed, this adds the idea that
links only distinguished by colour can be difficult to distinguish for
everybody.

Preview:
https://deploy-preview-4887--wcag2.netlify.app/techniques/general/g183

https://www.w3.org/WAI/WCAG22/Techniques/css/C41#tests

> The required change of contrast for Focus Appearance (Minimum) is 3:1,
this technique goes slightly beyond the minumum requirement.

The success criterion "Focus Appearance (Minimum)" was renamed "Focus
Appearance," and "Focus Appearance (Enhanced)" was deleted.
Therefore, the change of contrast ratio shown in the procedure should be
3:1 instead of 4.5:1.

EDIT by @patrickhlauke: also, while here, updated the CSS code sample to
match the following image

---------

Co-authored-by: Patrick H. Lauke <redux@splintered.co.uk>
Co-authored-by: Adam Page <adam@adampage.net>

…hniques (#5002)

As I constantly find myself having to explain to some folks that
techniques are just informative (the amount of times I had to explain
that even if a site doesn't use a particular documented technique,
that's fine as long as the actual ask of the success criterion has been
satisfied), this adds a standard boxout/disclaimer/note at the top of
all techniques pages. This should catch folks who just "stumble"
directly across a technique (from a search engine result or similar).

To go with it, this also expands the explanation given in the existing
boxouts on the techniques index page and the about page.

Closes #1567
Closes #3469

Previews:

* the top of the techniques index page "Summary" boxout
https://deploy-preview-5002--wcag2.netlify.app/techniques/
* [Diff from current
index](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG22%2FTechniques%2F&doc2=https%3A%2F%2Fdeploy-preview-5002--wcag2.netlify.app%2Ftechniques%2F)
* ditto at the top of the "About techniques" page
https://deploy-preview-5002--wcag2.netlify.app/techniques/about
* [Diff from current About
page](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG22%2FTechniques%2Fabout&doc2=https%3A%2F%2Fdeploy-preview-5002--wcag2.netlify.app%2Ftechniques%2Fabout)
* random example of one of the positive techniques
https://deploy-preview-5002--wcag2.netlify.app/techniques/aria/aria1
* random example of a failure technique
https://deploy-preview-5002--wcag2.netlify.app/techniques/failures/f1

---------

Co-authored-by: Kevin White <kevin@w3.org>

Wanted to follow up on
#2136

It isn't clear that it is a good example. Often folks find examples
where there are problems vs examples of it working.

---------

Co-authored-by: Patrick H. Lauke <redux@splintered.co.uk>