Re: Smartphones and phone-enabled tablets as examples for closed functionality

These are good but they still are “all or nothing” re Assistive technology

Remember that some smartphones. (iPhone is an example ). Allow the installation of different keyboards which allows any keyboard oriented AT to be installed.  
So I THINK the summary is

Smartphones etc.  
are closed to the addition of some types of AT. 
(Some may be closed to all but not all are closed to all AT)
They also have some types of AT built-into them  (but not all types)
Apps on smartphones
 may be closed to all AT (even built in AT)
Or they may be accidentally open to AT. (Because they were built with components provided by the startphone OS maker. — and the components were open to AT so some parts or all of the app may support the built in or installed AT accidentally.
or they may be open to and support all AT that the phone provides or allows to be installed

Now for requirements.  (Though we are not creating any requirement in WCAG2ICT
Products with any functionality that is closed should be providing the equivalent accessibility that the assistive technologies would provide
This is usually required for major functions of major types of AT and nothing more
One reason is that there can be a very large number oh, different types of AT and it would be difficult for the product designer to know what they all would be, and probably impractical to build all of the different types of AT into any product that  had closed functionality.
A good question is whether a phone app that is open to AT on the phone, inherits the closed aspect of the phone, and therefore has to provide equivalent accessibility for all of the functionality for all of the Assistive technologies that a user cannot use with the app because the phone does not allow it to.
If we were trying to ensure that people who needed all types of assistive technologies could use all of the functionality of all of the apps, then this is something that would be required.
However, it is difficult to conceive of how one would do this or enforce this or require this. The app is bound by the limitation of the operating system and it's hard to require that the app do something that the operating system won't allow it to. Or maybe a better way to say it is that it's hard for the app to provide the alternate accessibility for all of the types of assistive technology they cannot be used with the app when it isn't the app that's preventing the accessibility but the platform.
The temptation here would be to then just say that the app isn't responsible for anything more than making itself open to 80. If somebody else closes off the ATT, it's not the apps problem. However, if the app is running on a platform that has no ATT of any kind it would still have to acknowledge that it is inaccessible because there is no AT that will work with the app because of the platform it is running on.

So the whole issue is kind of complicated. And I think we need to find a balance between unrealistic idealism on one side and setting up something allows people to basically have products that people disabilities can't use and to simply say us not their fault and not their responsibility. We need to figure out something that's effective as it can be still being practical.

Wish us luck

Comments welcome on the first part of this. We need to get at least this part of it down Pat and something we can all agree on. What to do about it (the second part) is completely open to discussion. Don't have any answers there.

Gregg




> On Nov 9, 2023, at 10:02 AM, Mitchell Evan <mevan@tpgi.com> wrote:
> 
> Instead, I would like to up-vote Loic’s proposal:
>  
> “…telephony devices such as IP phones, feature phones, smartphones, and phone-enabled tablets. *Although smartphones have build in AT or AT-like features they are mostly (but not completely) closed to other AT*"
>  
> Or better:
>  
> “…telephony devices such as IP phones, feature phones, *and smartphones and phone-enabled tablets that prevent users from installing assistive technology*”
>  
> 

Received on Thursday, 9 November 2023 21:32:18 UTC