From c98fa521d76a8019607800c1c3f9dced521119da Mon Sep 17 00:00:00 2001 From: Mary Jo Mueller Date: Fri, 6 Sep 2024 16:01:18 -0400 Subject: [PATCH] Issue 427: Add 4.1.1 parsing to SC problematic for closed This change is per Issue #427 and [resolution from the 5 Sept. meeting](https://www.w3.org/2024/09/05-wcag2ict-minutes#r02). --- success-criteria-problematic-for-closed-functionality.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/success-criteria-problematic-for-closed-functionality.md b/success-criteria-problematic-for-closed-functionality.md index dab2ab34..5c176a29 100644 --- a/success-criteria-problematic-for-closed-functionality.md +++ b/success-criteria-problematic-for-closed-functionality.md @@ -65,6 +65,12 @@ For non-web software on products with closed functionality, those who implement
  • Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may be judged to take legal precedence over Success Criterion 3.3.8 Accessible Authentication (Minimum).
    • +
  • 4.1.2 Name, Role, Value — Requires information in a programmatically determinable form.
  • 4.1.3 Status Messages — Depends upon status messages being programmatically determinable using role or properties.
    Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.