On Mar 8, 2023, at 6:44 PM, Hakkinen, Mark T <mhakkinen@ets.org> wrote:
> Is there any precedent within W3C for changing an existing, versioned and published recommendation, agreed to previously in time by W3C membership? Is it an errata? Don’t think so. The concern is adequately addressed by deprecating (which I agree is the correct approach) in the latest, and member approved, specification. SC 4.1.1 appeared relevant to us at the time, it was approved, and remains part of WCAG’s history. Deprecate and move on in subsequent versions.
Chiming in to say I don’t think the concept of “deprecation” applies to WCAG Success Criteria. Deprecation is intended for Web API that may be no longer be supported in later versions of implementations. (E.g., ARIA deprecated the drag-and-drop attributes in 1.1, so avoid using them, but browser engine support may remain for a time.)
To “deprecate” success criteria doesn’t really make sense. Either it’s recommended success criteria, or it’s not. Since 4.1.1 is no longer necessary or recommended, what would “deprecation” mean?
For WCAG 2.0 and 2.1, I don’t have a strong opinion, other than: don’t call it “deprecated.” Choices seem to be:
Leave 4.1.1 as-is. (I agree with Mark that it’s not “errata.")
Remove 4.1.1 entirely, adding the note.
Strike 4.1.1, adding the note.
For WCAG 2.2, removing 4.1.1 with a note explaining its removal seems like the most reasonable approach. I don’t believe that leaving the legacy text in is helpful to web authors, implementors, or policy makers.
Thanks,
James