Major Flaw in Corona for Business Apps

Business Apps
#1

I don’t think Corona SDK would be all that bad to use for business applications. I’ve managed to produce some pretty clean UIs in Corona which could pass for a professional business app.

However I’m very hesitant to ever produce one for a client because of Corona’s lack of accessibility to disabled users.

Anyway, here is a list of accessibility features I think need supporting before anyone takes a Corona-based business app seriously.

 1) Dynamically changing font sizes/boldness based on OS user settings

 2) Support for iOS VoiceOver (and Android equivalent). Ideally, any displayObject could be given accessibility metadata which the OS would find. Also scrollviews should be navigable with VoiceOver.

I don’t think that (1) would be difficult to implement. Maybe I could make a plugin for this?

(2) seems like a major endeavor. But there are some hacks we could probably do to pull it off. I have some ideas of how to do it. I might share them after more thought.

Anyone else thinking about this? I think it’s a shame there is absolutely 0 support of accessibility features.

#2

For number 2

A. I was thinking of creating a plugin that reads the accessibility options of the device and then using a text to speech native library for each platform (or a generic library) mimics the functionality of the built in accessibility tools.

B. Somebody in these forums is working on a Flutter binding for Corona which I would suppose would natively support the accessibility options.

https://forums.coronalabs.com/topic/75648-mi-corazon-flutter-for-corona/?hl=flutter

#3

Let me start by addressing #1. I don’t know if Android supports similar font-size/boldness options under a system setting or not. We tend to only add API’s that are going to be cross platform. If there is an Android equivalent, the system.getInfo() could be expanded to get the preferences and get the values and then you could program your app.

But this is likely not something we are going to be addressed in the near future. However, Corona is open source and this would probably be a good project for the community to take on. I don’t think this would be hard.

As for the second issue, Corona is almost fully assembled from images. There isn’t a built in way naturally feed this to a screen reader. I could imagine that a new attribute be added called “.altText” that would mimic HTML’s " alt="" attribute on HTML pages. Anyone can add a method to any display object now. But how to get this bridged to a screen reader is not something I understand how that would hook up between screen reader libraries and Corona display objects. This sounds like a plugin to me. It’s a matter of finding someone to write it.

We are still face first in Android 64-bit issues and then we have to move to other high-priority items when we get that ironed out. Since we are now open source, both of these are community solvable. 

Rob

#4

I think Rob makes a good point. This is probably something for the community to take on. I’ve considered taking this on myself even.

A hacky way of implementing it would be to have a native element associated with each displayObject you give altText to. Somehow you’d have to get this invisible native object to follow closely enough to the displayObject that it just works. Like if the displayObject goes off screen, or is hidden, then the native element shouldn’t be available for the native accessibility features.

It would be hacky, but I think you could do it entirely with UILabels on the iOS side. Maybe just have UILabels which don’t receive touch events and that have a color with 0 alpha. Or just put the labels under the Corona canvas. Idk about Android.

Then again, this hacky solution wouldn’t give you all the accessibility features native apps have out of the box.

#5

I would not recommend this. Mainly because native objects always sit on top of OpenGL based objects. You can’t put them underneath display objects.

Rob

#6

For number 2

A. I was thinking of creating a plugin that reads the accessibility options of the device and then using a text to speech native library for each platform (or a generic library) mimics the functionality of the built in accessibility tools.

B. Somebody in these forums is working on a Flutter binding for Corona which I would suppose would natively support the accessibility options.

https://forums.coronalabs.com/topic/75648-mi-corazon-flutter-for-corona/?hl=flutter

#7

Let me start by addressing #1. I don’t know if Android supports similar font-size/boldness options under a system setting or not. We tend to only add API’s that are going to be cross platform. If there is an Android equivalent, the system.getInfo() could be expanded to get the preferences and get the values and then you could program your app.

But this is likely not something we are going to be addressed in the near future. However, Corona is open source and this would probably be a good project for the community to take on. I don’t think this would be hard.

As for the second issue, Corona is almost fully assembled from images. There isn’t a built in way naturally feed this to a screen reader. I could imagine that a new attribute be added called “.altText” that would mimic HTML’s " alt="" attribute on HTML pages. Anyone can add a method to any display object now. But how to get this bridged to a screen reader is not something I understand how that would hook up between screen reader libraries and Corona display objects. This sounds like a plugin to me. It’s a matter of finding someone to write it.

We are still face first in Android 64-bit issues and then we have to move to other high-priority items when we get that ironed out. Since we are now open source, both of these are community solvable. 

Rob

#8

I think Rob makes a good point. This is probably something for the community to take on. I’ve considered taking this on myself even.

A hacky way of implementing it would be to have a native element associated with each displayObject you give altText to. Somehow you’d have to get this invisible native object to follow closely enough to the displayObject that it just works. Like if the displayObject goes off screen, or is hidden, then the native element shouldn’t be available for the native accessibility features.

It would be hacky, but I think you could do it entirely with UILabels on the iOS side. Maybe just have UILabels which don’t receive touch events and that have a color with 0 alpha. Or just put the labels under the Corona canvas. Idk about Android.

Then again, this hacky solution wouldn’t give you all the accessibility features native apps have out of the box.

#9

I would not recommend this. Mainly because native objects always sit on top of OpenGL based objects. You can’t put them underneath display objects.

Rob