Update/correct 3.3.1 understanding

[patrickhlauke]

• remove the unnecessary reference to the "definition in WCAG 2.0"
• remove the now outdated "Currently, few technologies support this kind of programmatic information", as that's not true anymore
• clarify that programmatic information is not covered by this SC, but that others like 4.1.2 apply
• corrects link to error suggestion from "3.3.1" to "3.3.3"
• add ARIA2 as sufficient technique

Closes #1797, closes #1802

[jake-abma]

Change to WCAG might cause issues if WCAG 3 decides otherwise, WCAG 2 Series?

[patrickhlauke]

Any news on this @alastc ?

[bruce-usab]

Looks fine, but I am still not straight on cross ref syntax (line 76), and looking to be educated on (1/19) call.

...by other criteria such as <a href="#name-role-value">4.1.2 Name, Role, Value</a>.

Presumably that links back to WCAG. But should it link to Understanding doc for 4.1.2 ?

[WilcoFiers]

👎 as is, 👍 with my suggested edit (or something along those lines anyway)

[mraccess77]

SC 1.3.1 can be solved with programmatic information or with text - so while the SC may not require programmatic - I think we need to be careful in how we describe programmatic information such as required fields to SC !.3.1 if that information is available in presentation but not programmatically or as text. I think the key is if it is presented or not. If it's not presented visually then I would agree it would go to 4.1.2.

[patrickhlauke]

@mraccess77 I can see your concern here, but the added reference there that says this falls under 4.1.2 was in the context of the whole paragraph starting with "The identification and description of an error can be combined with programmatic information". i.e. that being in addition to other identification and description. Wonder if I should make that clearer somehow...any thoughts?

[detlevhfischer]

• In subsection "Sufficient Techniques for Error Identification" there are several empty list items / links that should probably be removed.
• There are two empty sections, "Resources for Error Identification" and, under "Techniques for Error Identification", "Failures for Error Identification". I guess these should be removed?

[patrickhlauke]

those were parts of the file i hadn't touched, and looking at the live version, it seems the xslt/publish script silently removes there. happy to rip them out of the file itself ...

[dbjorge]

Agree with patrick, I think this is actually just a case where the preview rendering is inaccurate. This happens because some of the links here are written in the source like this:

               <li>

                  <a href="https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21" class="aria"></a>
                  
               </li>

...which looks like empty list items as rendered by the preview, but when processed to build the live version, actually results in the <a> elements getting filled in using the title of the page (you can see an "ARIA21" link like the above example correctly in the rendered live page)

[detlevhfischer]

While we are at it, would it be worth covering the frequent case of inline error handling, e.g. mentioning the recommended position of error messages (if placed above the field these would easiliy be missed in SR reading mode)? Information could also indicate that these messages should be programmatically available (e.g. by inserting them in a programmatically linked label or referencing them with aria-describedby). If I get the gist of the reference to 4.1.2 in this PR, you think that failures to programmatically link error messages should be reported elsewhere, like the existence of the required attribute when the required state is visually indicated?

[mbgower]

While we are at it, would it be worth covering the frequent case of inline error handling, e.g. mentioning the recommended position of error messages (if placed above the field these would easiliy be missed in SR reading mode)?

@detlevhfischer If you want to open a new issue to include that, it's welcome, but I think it's important that we maintain a process of trying not to increase scope in PRs that have been put in front of the working group.

[detlevhfischer]

The idea of 3.3.1 is: ALL users should know that some error has occured. We have always thought it appropriate to cover missing programmatic linking of error messages, and programmatic identification of required state where indiated visually, under 3.3.1 since it is an aspect of the use case of realising that there has been an error. Is the added reference to 4.1.2 meant to indicate that that kind of error should be reported in 4.1.2 and not here? If so, that is not explicit now. I guess programmatic identification of errors might possibly be done in several ways (programmatically moving focus to the message?) that would not necessarily fall under 4.1.2. Another way would be 4.1.3, which is not referenced here - I guess it should be, by analogy.

I can see the advantage of covering aspects of bad errror handling under other SCs: 4.1.2 (messages not programmatically referenced) 1.3.1 ('required' indicated only visually), 1.3.2 (error message appears above the field), 4.1.3 (error status message not programmatically available) - BUT from the point of use of an audit report, this means the issues around error handling are widely dispersed across the report. I'm OK with that (because what it changes is nothing substantial, but only the allocation of errors to SCs), but I wonder if at least the programmatic availability of error messages is something that can usefully be reported under 3.3.1 (because it does not concern so much the value / state of a UIC but the availability / identification of the result of a user interaction).

[mbgower]

This is parallel to the way that 2.4.6 covers whether headings exist, but 1.3.1 would cover whether they are programmatically indicated as headings. It would be incorrect to fail 2.4.6 if someone used <p><strong>How to interpret 3.3.1</strong></p> instead of <h2>How to interpret 3.3.1</h2>, but it would not pass 1.3.1.

Likewise, injecting <p>The Name field is required</p> into the form after an attempt at submission would pass 3.3.1 (via G83: Providing text descriptions to identify required fields that were not completed), and I do not think you would get consensus that it fails either 1.3.1 or 4.1.2, although I think you would on it failing 4.1.3.

Finally it is fairly clearly established that we do not create a catalog of ways something could fail other SCs in the Understanding documents. I think the balance created here is reasonable.

[detlevhfischer]

Finally it is fairly clearly established that we do not create a catalog of ways something could fail other SCs in the Understanding documents. I think the balance created here is reasonable.

Yes, I see the point in that. But my point was that there are reasons to fail unreferenced error messages here, in 3.3.1, as this cannot easily be captured under 4.1.2 (it is not narrowly a name, role or value of an UIC that is at fault) and arguably 1.3.1 is met if output is available in browse mode. And it is an accessibility issue that should be captured somewhere - why not here?

I am not in the way of progressing this PR without such addition, though, and to create a separate PR for it.

[mbgower]

Thank you, please open a new issue/PR to address your concerns.

[detlevhfischer]

Rendered view (19. Feb 2024, 11:10)

Conversation with the requester has shown that these items can be dealt with in a separate issue/PR which he has agreed to.