Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessible Platform Architectures WG review #419

Closed
anssiko opened this issue Jan 27, 2016 · 9 comments
Closed

Accessible Platform Architectures WG review #419

anssiko opened this issue Jan 27, 2016 · 9 comments

Comments

@anssiko
Copy link
Member

@anssiko anssiko commented Jan 27, 2016

Accessible Platform Architectures WG submitted the following review comments via public-webapps:

Participants in the Accessible Platform Architectures Working Group reviewed Web App Manifest https://www.w3.org/TR/appmanifest/ and have the following comments:

Substantive Comments

splash_screens

  • There is no method to provide text alternatives for splash screens. While not their primary purpose, splash screens are sometimes used to convey hints and tips about how to use an application. The manifest provides no method for a developer to provide that same information in a textual form.

Editorial comments

  • A number of places where the colour contrast ratio of 4.5:1 is not met (red text within issue sections, yellow and green text within Examples, green text within Note sections
  • Figure 1 should have some type of long description for the image
  • The are 3 unlabeled checkboxes in the Issue 323 section.
@anssiko anssiko closed this in 04d72e1 Jan 27, 2016
@anssiko

This comment has been minimized.

Copy link
Member Author

@anssiko anssiko commented Jan 27, 2016

Thanks for your feedback APA WG.

splash_screen

A splash screen indicates to the end user that a loading process is occurring. Thus an implementation can provide a generic "Loading ${name} application..." using the name (or short_name) in cases where textual representation is preferred over visual.

Editorial comments

A number of places where the colour contrast ratio of 4.5:1 is not met (red text within issue sections, yellow and green text within Examples, green text within Note sections

This specification uses ReSpec with its default stylesheet. I recommend you report these issues at https://github.com/w3c/respec and help make the ReSpec stylesheet more accessible.

Figure 1 should have some type of long description for the image

Fixed.

The are 3 unlabeled checkboxes in the Issue 323 section.

These issues are pulled into the spec programmatically using the GitHub API integration in ReSpec. I recommend you open an issue at https://github.com/w3c/respec to help improve this.

@anssiko anssiko reopened this Jan 27, 2016
@anssiko anssiko closed this Jan 27, 2016
@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Jan 27, 2016

Adding "alt" to image object might be useful - however, I'd like to know if any platform supports this capability for splash screens.

@cynthia

This comment has been minimized.

Copy link
Member

@cynthia cynthia commented Jan 27, 2016

In the even adding a new property is undesirable (e.g. splash_description) a generic loading application name as filler alt text is probably enough as @anssiko noted. If possible, throwing in a may (or a must, for aria supporting implementations) clause for implementations to set aria-busy on the document context to true (and false otherwise) when the splash is being shown could be useful.

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Jan 27, 2016

@cynthia good suggestions. One limitation is that the splash screen is shown before the document is loaded: it's meant to show up while the OS bootstraps the browser engine. Thus, it would be too early to interact with the Document. The splash screen is supposed to go away on first paint.

However, need to check what OSs do when launching native applications... there might be a way of interfacing with AT through some other means at launch time.

@cynthia

This comment has been minimized.

Copy link
Member

@cynthia cynthia commented Jan 27, 2016

@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), the busy status could be marked there, since all the user needs to know is that something is busy.

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.

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Jan 27, 2016

@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.
  2. double tap to open the app.
  3. iOS makes a "click" confirmation sound when splash screen is shown.
  4. 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?

@cynthia

This comment has been minimized.

Copy link
Member

@cynthia cynthia commented Jan 27, 2016

iOS makes a "click" confirmation sound when splash screen is shown.

To get the alt text rect, you have to touch the splash screen at this stage. (Try loading a app that has long load times. I used Spotify.) As long as there is a mechanism defined in the spec that allows the OS to tell the user which app the splash screen is for, and that it's there because it's loading, I think it's good enough. (Making it definable in the manifest by the developers would work in a ideal world, but it's very likely to be neglected or incorrectly used.)

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Jan 29, 2016

@cynthia ah, got it! Hear the app's name now :)

@cyns

This comment has been minimized.

Copy link

@cyns cyns commented May 11, 2016

since this has come up twice now, @cynthia is not me :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.