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

Thanks Gregg. I agree all of those degrees of openness and closedness can and do occur. I’ll try addressing the range of possibilities not in the list of device types, but in the preceding sentences that give the list context.

Key points: ICT can be “partially or fully” closed. The examples here have “historically” been closed — implying that future wearables, TVs, or even self-service terminals could be more open than they are today.

Proposed, with [DELETIONS in brackets] and additions in *bold*:

As noted in the Introduction, WCAG 2.2 assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Many of the success criteria in WCAG 2.2 assume web content will be accessed by ICT where assistive technologies can be connected to it or installed on it. The assistive technologies then present the web content to people with disabilities in an accessible form.

[DELETE: ICT products with closed functionality<https://deploy-preview-254--wcag2ict.netlify.app/#closed-functionality> do not allow the use of some assistive technologies for all of their functions. In many cases such ICT products also lack a “user agent” or its equivalent.]
*When an ICT product has closed functionality<https://deploy-preview-254--wcag2ict.netlify.app/#closed-functionality>, the closed portions of the product prevent users from attaching, installing, or using one or more kinds of assistive technology. Closed functionality can occur in varying degrees. An integrated hardware and software product might be completely closed, such as a payment terminal that provides no user agent for its content nor the opportunity for users to install any kind of assistive technology. An operating system for handheld or wearable devices might be partially closed, restricting the user’s choice of assistive technology software yet allowing keyboard pairing. While an operating system imposes its limitations on all apps that a user installs on it, an individual app on an otherwise open platform might implement its own closed functionality.*

[DELETE: As a result, ICT following the WCAG success criteria by themselves will not make information accessible on ICT with closed functionality.]
*To the extent a software product is closed, following the WCAG success criteria by themselves will not make the software accessible.* Where assistive technologies or user agents are not available to address the intent of these success criteria, something else needs to be provided or be required to facilitate accessibility as WCAG 2.2 intends. It is outside the WCAG2ICT Task Force Work Statement<http://www.w3.org/WAI/GL/task-forces/wcag2ict/work-statement> to say what the additional measures are, but this Note points out which success criteria depend on assistive technologies—and therefore would not work by themselves in [DELETE: products with] closed functionality.

[DELETE: Example: Several examples the task force has considered when developing guidance include the software of:]
*In developing guidance for closed functionality, the task force has considered examples of ICT that historically have been partially or fully closed to assistive technologies:*

  *   [List of device types]


Mitchell Evan (he/him)
Senior Accessibility Engineer

[Tpgi]
TPG Interactive
www.tpgi.com<https://www.tpgi.com/>

A Vispero Company
https://vispero.com/

+49 1525 89 50 540
+1 510 375 6104

This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately.
Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.

From: Gregg Vanderheiden <Gregg@vanderheiden.us>
Sent: Thursday, November 9, 2023 10:32 PM
To: Mitchell Evan <mevan@tpgi.com>
Cc: public-wcag2ict-tf@w3.org
Subject: Re: Smartphones and phone-enabled tablets as examples for closed functionality

CAUTION:EXTERNAL EMAIL SENDER!

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*”