Recently I was doing an WCAG audit of native mobile app and noticed a user experience pattern that would normally require a status message being announced to assistive technologies like screen-readers. The pattern was good old search results update after user confirms search terms and some results can be displayed (or just a warning about no results).
Now this may be quite obvious when auditing web pages and web applications but what about native mobile apps?
WCAG success criterion 4.1.3 (Status messages) is referring to markup languages
Although it feels natural that WCAG 2.1 can and should or even must be applied to native mobile applications I had my doubts with success criterion 4.1.3 as it refers to markup languages. Are native mobile apps markup language-powered? Don’t think so. Should native mobile apps support status messages – I strongly believe so.
Success Criterion 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.
WCAG 2.1 – success criterion 4.1.3 Status Messages (opens in new window).
In my audit I also had to cover EN 301 549 V3.2.1 (2021-03, PDF opens in new window) and there it is quite easy to find what applies for native mobile apps and what not. On page 96 you can find the Table A.2: Mobile Applications – relationship between the present document and the essential requirements of Directive 2016/2102/EU. Then if you go to page 103 you can find it – under number 136; marked as 11.4.1.3 Status messages (open functionality); “when ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen-reading”.
So it seems like EN 301 549 is absolutely requiring the 4.1.3 for native mobile apps.
I still wanted to check if official WCAG maybe suggests otherwise, just to be sure; As far as I can understand based on comments about this on GitHub the markup languages part was there because of Flash and Java (opens in new window).
OK, so native mobile apps don’t need to respect 4.1.3 because they are not made with markup languages, but at the same time we have to check it if we are testing for EN 301 549 V3.2.1.
Android and iOS methods for status messages
I am not a native mobile app developer, just to make that clear. But I did some testing with Android and I loved playing with React Native. So I started to check what are thee possibilities for native status messages.
In some audits I’ve been reading that iOS does not support status messages, but Android does. I’ve wanted to check it for myself. Things change and hey – we are only people.
React Native supports status messages out of the box, but…
As I have some limited experience with React Native and as it is really doing amazing work on supporting both Android and iOS I decided to first check if they have some kind of support for status messages first.
When you search the React Native documentation you can find “announceForAccessibility” (opens in new window) and “announceForAccessibilityWithOptions” and it seems like they do exactly what we need – send status messages to screen-readers. With options version even explains why it is usually needed (screen-readers can read out other text and miss announcements (sounds like a real usability problem for people with disabilities to me).
I tried to test this quickly and for quick testing I like to use Expo.io’s snacks. But there I found out that latest version of Expo (SDK45) did not have the “With Options” version yet (opens in new window). So I just tested with a simple button that runs “announceForAccessibility”. Nothing was announced, nothing but the button. Quite disappointing to be honest. I just wrapped it in a setTimeout with two seconds delay and – it worked. So I look forward to having “announceForAccessibilityWithOptions” in Expo as well. I think it will fix the issue for me. At least hope that it will.
I love the open source because i enables us to check what is being used behind the React Native scene – and it seems to be “UIAccessibilityPostNotification” (opens in new window). So this actually confirms that iOS has the native capability for status messages (opens in new window).
On the other hand we can check the implementation for Android and there we can found “AccessibilityEvent.TYPE_ANNOUNCEMENT” is used (opens in new window). I’ve also seen native Android Toast messages used as an announcements and am guessing that they can also do the job provided we test the pattern with real users.
Conclusion – use of status messages on mobile is possible
Use status message mechanisms on native apps even if you may be in doubts. Testing with screen-reader users will for sure reveal how useful they are. Form validation, app feedback where context is not changed, search results and practically all changes of content that are smaller in nature should be announced to screen-readers.
