Re: [manifest] Accessible Platform Architectures WG review (#419)

> @marcoscaceres Then I guess it would be quite implementation dependent. If it is the launcher's role to show the splash screen (and given that the launcher is also a document),

This is not guaranteed. For example on Android, the launcher is the native homescreen of the OS and not a Document.  

> the busy status could be marked there, since all the user needs to know is that something is busy.

Correct - however, the splash screen was really added for implementers that needed to bootstrap browser engines in non-document contexts: spinning up documents is fast once you've done it once (hence splash screens are not needed, and would just annoy users). 

What we need to find out is exactly what the AT does on each OS on launch for native apps (i.e., to adhere to each OS's conventions)...

> For dumb surfaces (which is what I assume a lot of OSes do) alt seems to be the easiest way out. iOS seems to just put a accessibility layer alt text rect on top of the splash screen, for example.

I'm checking voice over on iOS, and this is what I'm experiencing (not sure if this matches what you describe above):
  
 1. activate the icon and iOS speaks the name of the app. 
 1. double tap to open the app.
 1. iOS makes a "click" confirmation sound when splash screen is shown. 
 1. app is loaded and shown. On ready, "click" confirmation sound is emitted.

So, at least on iOS, after trying a few apps, it seems that none read any alt text for the splash - but only give an indication that that app is ready to use. It could be that for the apps I tried, people didn't provide any alt text.  

Can someone please check what happens on Android? 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/419#issuecomment-175570781