Apply SC 4.1.3 Status Messages to native code in software

Currently

11.4.1.3 incorporates WCAG SC 4.1.3 Status Messages by reference with no modification.

As a result:

• WCAG's normative applicability to "markup languages" means the criterion is limited to web views in an app, and excludes native code in the same app.
• This restriction makes accurate auditing of this criterion impossible for native apps. In black box testing, there is no generally-available method for a tester to determine whether a web view is present or to locate boundaries between web views and native code.

Proposed

Apply WCAG SC 4.1.3 Status Messages to native code where supported. EN 301 549 may wish to use language as in this 2023 WCAG2ICT draft:

In [content implemented using markup languages, or that supports status message notifications], status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Background

The above draft was in line with community requests. However, the Task Force later removed the word substitution, with a further recommendation in our February 2024 decision (emphasis mine):

...We determined the WCAG2ICT Task Force is not at liberty to expand the scope of the WCAG success criteria beyond what WCAG states - to "content implemented using markup languages".

However, we do agree that it makes sense to more broadly apply to non-web software, and so new notes were developed to indicate that. This will inform outside standards development organizations that they should consider broadening the scope or writing an additional requirement that parallels the WCAG criterion, as they see fit.

Here is the relevant WCAG2ICT note for SC 4.1.3 Status Messages:

For non-web documents and software where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus. This is typically enabled through the use of accessibility services of the user agent or platform software.

Benefits of the proposed change

• It addresses the current difficulties for audit testers.
• It benefits users, who have the same user needs regardless of whether app content is implemented in a web view or in native code.
• In platforms with support for status messages, such as iOS and Android, effort for an app developer is similar to that for a web developer.

changed the description

changed the description

I am very uncomfortable with diverging the EN from the agreed W3C text to some unpublished draft.

Therefore, I would not support using the 2023 draft language. The EN should align with the final WCAG2ICT guidance.

Would it be feasible as a sub-clause of 11.5 instead?

I think that the best approach is to:

• keep 11.4.1.3 as a simple link to the WCAG SC, like many other clause 11 requirements, and not try to extend that beyond its explicit applicability to markup languages (as @jeffreym proposes).
• add a note to 11.4.1.3 that says that where the software is not implemented using markup languages, or where it is not clear whether the underlying software uses markup languages, 11.4.1.3 is not applicable (this reason for the requirement not being applicable can be incorporated in the matching test in C.11.4.1.3) and that the new clause 11.5.x that @mtchllvn proposes is applicable
• draft a new clause 11.5.x that captures what should be done in a testable way.

Perhaps @mtchllvn could propose a starter requirement and suggest where he thinks it best fits in clause 11.5?

How about this @mtchllvn @pluke :

11.5.3 Status messages (generic)

Where ICT is non-web software that supports status message notifications, status messages can be programmatically determined so that they can be presented to the user by assistive technologies without receiving focus.

NOTE 1: This clause complements WCAG based clause 11.4.1.3 Status messages. The referenced WCAG success criterion 4.1.3 applies only for content implemented using markup languages, but the WCAG2ICT Task Force has concluded [REF1] that even "where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus".

NOTE 2: The term "status messages" is defined in WCAG 2.2 [REF2]

[REF1] https://www.w3.org/TR/wcag2ict/#applying-sc-4-1-3-status-messages-to-non-web-documents-and-software

[REF2] https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html#dfn-status-message

And adding a note to 11.4.1.3:

NOTE 1: In order to keep this clause aligned with WCAG success criterion 4.1.3, it applies only for content implemented using markup languages. But clause 11.5.3 presents an analogous requirement for other types of content.

I would suggest we say "standardised markup languages". It has been pointed out to me that some software UI designs are implemented using proprietary (sometimes rather weird) markup languages that are internal to the design development environment and not easily (or openly) available for other software to read or interpret. HTML and variants of it are not the only things out there.

Microsoft Silverlight and Adobe Flash are a couple of past examples, and there are probably more still out there.

Good observation @jeffreym, I agree this is a problem when trying to apply the current WCAG SC to non-web ICT.

But the reference to "markup languages" is in the WCAG SC (which we cannot change), and as we are now trying to construct a clause 11.5.3 to cover all relevant cases that the WCAG SC is missing, I don't think there is any need to be more precise in exactly where the border between 11.4.1.3 and 11.5.3 is drawn. I believe the practical implications of any such re-wording would be negligible or at least very small.

@jeffreym is right, about the past, present, and even future non-standard "markup languages" that are used internally within software. But this may not be a major issue as:

• WCAG does not define precisely what it means by markup languages
• we will have both 11.4.1.3 and the new 11.5.3 that are both requiring the same thing so if someone decides to use 11.4.1.3 because they are aware that the software is markup language based, and other people use 11.5.3 they will both be testing the same thing. In fact, according to the above formulation of 11.5.3, 11.4.1.3 is actually redundant as 11.5.3 will always apply whether or not the software is based on markup languages!

Strictly speaking the two requirements should have complementary pre-conditions in EN 301 549:

• there should be an additional pre-condition on 11.4.1.3 of "where content is implemented using markup languages" to give:
  • "Where ICT is or includes non-web software that provides a user interface, and where content is implemented using markup languages,"
• and the pre-condition for 11.5.3 would become:
  • "Where ICT is non-web software that supports status message notifications, and where content is not implemented using markup languages,"

This would then mean that depending on whether or not the evaluator believes that the content is implemented using markup languages, they would evaluate with one or other of the requirements, and they would identify the other requirement as "Not applicable", because the pre-conditions had not been met. Hopefully problem solved!

I think this makes sense, however it would be helpful if an evaluator recorded which option they chose, why, and how they tested it. I would not like to see conflicts between the opinion of the manufacturer and that of the evaluator leading to the pointless exclusion of a product.

But I think that what will be tested will be independent of which of the two requirements the tester (rightly or wrongly) chose. If the evaluator is doing their job thoroughly, one of the requirements will be marked as pass or fail and the other one will be marked as not applicable. As the note on 11.5.3. shows the link between the two I do not think that it is essential for the evaluator to formally record which one they used.

I cannot see how there could/should be any wrangling that could lead to "the pointless exclusion of a product", it would only be excluded if it failed both of the requirements (rather than failed one and had a not applicable mark for the other), which would indicate that the evaluator didn't do their job thoroughly, but it would also indicate that the product deserves to be excluded - no argument.

added WCAG2ICT label

marked this issue as related to #537

marked this issue as related to #538

mentioned in issue #538

Prompted by the issue #538 by @salaetsk I have read through this thread again. It seems possible to get consensus on a solution where we have two complementary clauses 11.4.1.3 and 11.5.3, the first mirroring WCAG SC 4.1.3 and the other for cases not implemented with markup languages. Together, these two clauses should cover all relevant cases and align with the WCAG2ICT recommendation.

I propose the following wording for those two clauses:

11.4.1.3 Status messages

Where ICT is, or includes, non-web software that provides a user interface, and where content is implemented using markup languages, the software shall satisfy WCAG 2.2 Success Criterion 4.1.3 Status Messages.

NOTE 1: In order to keep this clause aligned with WCAG success criterion 4.1.3, it applies only for content implemented using markup languages. But the same user need exists even for content not implemented using markup languages. Therefore, clause 11.5.3 complements this clause with an analogous requirement for such content.

11.5.3 Status messages (generic)

Where ICT is non-web software that supports status message notifications, and where content is not implemented using markup languages, status messages can be programmatically determined so that they can be presented to the user by assistive technologies without receiving focus.

NOTE 1: This clause complements WCAG based clause 11.4.1.3 Status messages. The referenced WCAG success criterion 4.1.3 applies only for content implemented using markup languages, but the WCAG2ICT Task Force has concluded that even "where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus".

NOTE 2: The term "status messages" is defined in WCAG 2.2