4.1.3 Status messages and native applications

[patrickhlauke]

4.1.3 Status Messages (Level AA): In content implemented using markup languages, 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.

that first sentence "In content implemented using markup languages" in practice exempts native applications. I'm not sure this was actually intended? Particularly looking at, say, native apps that show toasts/notifications, this means generally that there's no SC that would apply if those notifications are not announced at all?

[EmanuelaGorla]

I agree. That means it is also not applicable to inline error messages displayed in native apps, which are often not announced by screen readers when appearing on screen, resulting in screen reader users not knowing that forms contain errors.

[bruce-usab]

At the time, the restriction to content implemented using markup language was quite deliberative. We didn't think we had standing to apply this SC to things like Flash and Java. That was well before anyone was thinking about mobile OS native apps, or before any had the idea to apply WCAG to desktop software.

[patrickhlauke]

That was well before anyone was thinking about mobile OS native apps, or before any had the idea to apply WCAG to desktop software.

the heady days of 2018 :)

[mraccess77]

It was deliberate - being as this was from 2018 folks were thinking about mobile app, however WCAG is aimed at web content and folks likely didn't want this applied to content like PDF where this might not be supported. So adding that was the easiest solution to exclude web content where there was not a mechanism.

[patrickhlauke]

Suggest that for "WCAG 2.1 to ICT" this exclusion/scoping should probably be lifted, if it hasn't already in whatever draft form it may be in at this point

[alastc]

My recollection aligns with Jon's, it was deliberate to avoid hitting unknown scenarios where it might not be feasible.

We're gathering people to work on wcag2ICT now, please email me if you're interested.

[maryjom]

Moved to WCAG2ICT repository as the new TF will work to address issues tagged as WCAG2ICT from the WCAG repository.

[detlevhfischer]

Whatever the intention of its WCAG authors, today 4.1.3 is included in clause 11 (Software, applicable to native apps) in EN 301 549 v.3.2.1:

EN 301 549 V3.2.1 (2021-03)
Where ICT is non-web software, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

[maryjom]

@detlevhfischer EN 301 549 also applied 4.1.3 to non-web documents. I'm not sure all documentation types have semantic markup for status messages that can be exposed to AT. There are no notes or caveats in the EN to describe those kinds of issues. This is why the WCAG2ICT work is important to get done.

[mraccess77]

EN 301 549 does refer to the SC - but the SC states in content implemented with markup languages - so if the non-web document or software isn't implemented in markup languages then the criteria doesn't apply.

Annex C for 10.4.1.3 : Not applicable: Pre-condition 1 is not met or the non-web document does not contain content relevant to WCAG 2.1 Success Criterion 4.1.3 Status Messages.

[detlevhfischer]

@mraccess77 wrote:

EN 301 549 does refer to the SC - but the SC states in content implemented with markup languages - so if the non-web document or software isn't implemented in markup languages then the criteria doesn't apply.

My point is that by referring directly to 4.1.3 and its scoping to mark-up languages, the EN authors have created an unnecessary gap in the Status Messages requirements for apps. It is both technically possible and desirable to expose status messages in native apps.
Which leads to the paradox that the Procedure (in Annex C 11.4.1.3 of the EN 301 549 v.3.2.1) is self-defeating;

1. Check that the software does not fail WCAG 2.1 Success Criterion 4.1.3 Status messages.
   Result
   Pass: Check 1 is true
   Fail: Check 1 is false
   Not applicable: Pre-condition 1 or 2 is not met, or the non-web software does not contain content relevant to G 2.1 Success Criterion 4.1.3 Status messages

If the intention (as it should be) is to apply the 4.1.3 requirement to apps there needs to be a correction here, stating that in its application to software (native apps) the constraint on content implemented in mark-up languages is lifted.

As an aside, it leaves us with a situation that we may apply 4.1.3 selectively to content in webviews of apps (even if we cannot inspect the source code) while exempting it for native content of the same app, which is less than ideal, to put it mildly.

[bruce-usab]

This is a good catch about 4.1.3. With 2.0, it is only 4.1.1 parsing with the content implemented using markup languages exception. With 2.1, there are three more.

[mraccess77]

Before 4.1.3 many were using the language in SC 4.1.2 to flag these types of issues. The SC includes the text "and notification of changes to these items is available to user agents, including assistive technologies."

[Lboniello]

@maryjom what is left for me to do here? Thanks!

[maryjom]

@Lboniello When you work on draft content for 4.1.3 I wanted you to be aware of this issue and discussion which had previously been opened in the WCAG repository. Hoping this will help with our WCAG2ICT notes for this SC.

[mitchellevan]

Proposals for WCAG2ICT

Option 1: in the spirit of SC 4.1.3

Word substitution: replace "In content implemented using markup languages" with "In content implemented using markup languages or other technology with support for content change notifications"

Note 1: A web view in a hybrid app is an example of content implemented using markup languages.

Note 2: Android and iOS native code are examples of other content technologies with support for content change notifications. In applications on these platforms, native code can notify assistive technologies that a content change has occurred and should be announced to users.

Advantages: It's good for users. It's not hard for mobile app developers. It's much easier for black-box testing of apps, where the exact boundaries between native code and web code are usually impossible to determine.

Disadvantage: Does the word substitution exceed what WCAG2ICT can do?

Option 2: lawyering

Note 1: A web view in a hybrid app is an example of content implemented using markup languages.

Note 2: Some non-web content technologies, such as native code in Android and iOS applications, can notify assistive technology that a content change should be announced to users. In these technologies it is a best practice to announce status messages.

[maryjom]

See the proposed guidance in Issue #122. Does it sufficiently address the scenarios you brought up @patrickhlauke?

[maryjom]

The TF reached consensus on the guidance for SC 4.1.3 on 30 March. The AG WG reviewed 4.1.3 in the 3rd content review and approved the content on 25 July. If you have questions or comments on the guidance provided on 4.1.3 Status Messages in the WCAG2ICT FPWD, please open a new issue.