4.1.2 Name, Role, Value content for the SC Problematic for Closed Functionality section

[maryjom]

Starting this discussion so that we can have a non-meeting discussion to work on on the proposal for what should be said for 4.1.2 Name, Role, Value content in the SC Problematic for Closed Functionality section.

Here are the important links to refresh your memory on what was surveyed and discussed.

• survey results for the last proposal
• In-meeting discussion on the survey results and search for "4.1.2" to get to that topic.

We need some solid proposals for what to say. I will voice my concern with statements made in the meeting that any product that doesn't provide programmatic Name, Role, Value would be inaccessible. A direction we could go is to say that there are cases for closed functionality where there is no accessibility API that supports programmatic information....and then decide what to say about that - perhaps, this success criterion, as written, would not be able to be supported.

Here's a link to the Google doc where you can see the already general section (Consensus reached back in June) and the proposed SC problematic for Closed Functionality content all together in one place.

[mraccess77]

I would prefer option 3 to still require the information but allow it to be met in ways through closed functionality AT. The term programmatically determinable seems to allow for this. So perhaps it to clarify that programmatically determinable allows for this.

[maryjom]

The problem is that this is not really applicable to all varieties of ICT with closed functionality. For single-purpose closed functionality products (e.g. printers, etc.) there is no true operating system on board, no accessibility API, no AT - things that this SC assumes is always present. The software in these cases is likely a simple menu-driven interface. Having a full blown programmatic identification of name, role, value might not even be necessary in such a situation, yet the product can still be accessible.

An example is a printer that is self-voicing, and it may also have voice-driven commands but does not contain an AT in the traditional sense. The device may even use another system (Alexa, Google dot, etc.) to do voice recognition and voice output which causes some back and forth communication to the device to operate a particular function (e.g. print a document) or obtain specific information (e.g. printer cartridge status) for the printer. The voice commands would be captured/understood by the external device and that causes a specific command in the menu-driven interface to be sent to the device for a user to access the desired functionality. In such a system, there isn't a direct need for literally providing the programmatic name, role, and value.

Since it isn't up to WCAG2ICT to define any changes other than word substitutions in the SC or definition, we can only point out that in situations of closed functionality there may not be any AT or AT-like interaction, but alternate means is used to provide the user with the appropriate level of information for someone with a disability to use the functionality.

[mitchellevan]

@maryjom, what we say for 4.1.2 (closed) will depend on what we say in the following sections:

• Closed Functionality (Key Terms)
• Closed Functionality (section)
• Success Criteria Problematic for Closed Functionality — the introductory text above the list of criteria

How do I find any open pull requests or alternate proposed edits for these sections? Before I can propose further edits for these sections or for 4.1.2 (closed), I need to understand what we're starting from.

For example, the following phrases are relevant to 4.1.2, and I know that in November @GreggVan and I emailed you alternate proposals for some of these phrases and sections:

...ICT following these success criteria by themselves will not make information accessible on ICT with closed functionality.
...
Where assistive technologies cannot be used, other output and input solutions are needed to achieve the intent of these success criteria.
...
...these criteria, as written, are not always applicable to closed functionality...
...alternate accessibility provisions might be needed to cover the user needs...

[maryjom]

See the google doc I created to see if all of the info you need is there for this focused 4.1.2 Name, Role, Value discussion.

[bruce-usab]

I am good with all the options except 2 because "does not apply" can be read as satisfying the SC.

statements made in the meeting that any product that doesn't provide programmatic Name, Role, Value would be inaccessible.

Such products might be accessible, and might conform to other accessibility standards for closed products, but such products would not meet this SC and I think it is important for wcag2ict to be clear about that.

For non-web software, including (native) mobile apps, WCAG conformance (after term substitution) is necessary for accessibility, but it might not be sufficient. With 508, we have a requirement for interoperability with assistive technology which applies to non-web software (and native mobile apps are software).

[maryjom]

Answered Mitch's question directly to keep this discussion purely about the 4.1.2 proposal.

[mraccess77]

It is my interpretation that printers due indeed have operating systems. In fact, almost all modern printers also have web servers as well. If a printer were to have text to speech and so forth it would need an OS to function. Linux is an example of an OS that may be command line but still nonetheless is an OS. I do agree that the intent of 4.1.2 is to make sure that type of information name, role, state is available somehow and that with closed functionality it could be provided in different ways. I do hesitate to believe that text to speech would be sufficient for all aspects of 4.1.2's intent but I believe other accessibility features that were built in could provide those.

[GreggVan]

Indeed. there are a million devices with - lets call it a platform - underneath. The question is not that - but whether the underlying platform as built in accessibility. If it doesn't then it is not much more than a library or development platform -- it is just premade code that the device software doesn't need to write itself. We talk about these things as embedded software. But whatever - the key is that if the product is closed or has closed functionality - none of this is relevant. The product can provide all of the accessibility that is required by itself - or if the platform under it provides some - then it can rely on that. If the platform provide some AT like functions - the app can open itself to them and save itself some work. Printers typically don't have a platform with AT in it - but they could. For closed products -- 4.1.2 and all of the 'programmatically determined' SC should be grouped together and just say -- "these all are designed to support AT. If a product or its functionality are closed to AT - then none of these apply and what they are intended to provide (through AT) needs to be provided in some other way by the product. And then we should stop. Anything beyond that is outside of our writ I believe.

[patrickhlauke]

4.1.2 and all of the 'programmatically determined' SC should be grouped together and just say -- "these all are designed to support AT. If a product or its functionality are closed to AT - then none of these apply and what they are intended to provide (through AT) needs to be provided in some other way by the product. And then we should stop. Anything beyond that is outside of our writ I believe.

That seems the most pragmatic and logical approach here, indeed. Otherwise, it's all very theoretical - "this does expose things programmatically so it could be exposed to AT if the platform/embedded system had it" (and also, not really testable unless as an auditor you have access to special dev environments/tools)

[mraccess77]

While I agree that these may not fit - I do believe programmatically determinable doesn't require any accessibility API and any other methods could be used. SC 1.3.1 also allows for text to meet it. Many years ago window classes, window states, and title text could be used to meet programmatic available requirements because if they were consistently available in ways that could be reached.

[mitchellevan]

@GreggVan wrote:

4.1.2 and all of the 'programmatically determined' SC should be grouped together and just say -- "these all are designed to support AT. If a product or its functionality are closed to AT - then none of these apply and what they are intended to provide (through AT) needs to be provided in some other way by the product. And then we should stop. Anything beyond that is outside of our writ I believe.

But I share @bruce-usab's concern about "does not apply." This phrase would equate to a pass, and I still don't think we can say software passes 4.1.2 just because it has a built-in screen reader. Some software could, as Jonathan pointed out, but not all.

Patrick is right, an independent tester can't know if software offers potential for interoperability where inspection tools aren't available. This might be exasperating but it's not WCAG2ICT's problem to solve. As a tester faced with this puzzle, I have a few choices...

1. If we're focused on usability over WCAG conformance, I would give high marks for good built-in AT.
2. Instead of using WCAG, we could evaluate the closed functionality software using a different standard. Section 508 evaluates closed functionality software as if it were hardware (Chapter 4). EN 301 549 applies the requirements of clause 5.1 Closed Functionality.
3. If I'm helping the developer make their own WCAG conformance claim, and they say the software itself is interoperable* with AT, then I'd tell them they can claim 4.1.2 passes, provided that we can observe platform-appropriate** AT output behaviors for interactive controls on an integrated system. Software designed to run on locked-down Windows kiosks could be an example of this scenario. The software considered on its own would actually be open, but the integrated kiosk would be closed.
4. If I'm acting as an independent evaluator with my name on the conformance claim: First I would look for AT behaviors, and 4.1.2 might fail just based on problems there. If it behaves well, then I could look for evidence of interoperability, and finding none I would have to give it a technical fail for 4.1.2. In my report remark, I would first point out the good user benefit with no observed defects in the built-in AT function, then state that the failure was based only on lack of evidence of interoperability.
5. Building on scenario 4: Suppose the software really does have interoperability. If the developer is motivated, they could buy or build a legitimate inspection tool for the programmatic information, put the integrated system into a test mode, and earn a pass for 4.1.2 (as in scenario 3).

Reflecting on these scenarios, I notice a few things.

• It's more complicated but still possible to evaluate 4.1.2 without inspection tools.
• Even in scenario 4, where the evaluator presumes 4.1.2 fails, the failure provides useful information which can lead to remediation.
• There is potential long-term benefit for users. If the platform later adds more built-in AT, the open software is ready*** for it. If the platform later becomes more open, the open software is ready for the user's choice of AT.

* In this context, "interoperable" is shorthand for "the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents." In an integrated closed system, built-in AT might be the only user agent.

** "Platform-appropriate" because interaction norms for kiosks can differ from those for web. For example, a screen reader could announce control names and keypad instructions, or even just control names without role information. Compare this with common screen readers' announcements for menu items in native desktop software, or for ARIA menuitems on web pages.

*** By "ready" I don't mean it would work perfectly right away, but it would be a lot closer.

[mitchellevan]

Built-in AT "helps meet the intent" was to express that it's a good thing, but may not (or does not) satisfy the normative requirement.

Same concept, another option: Built-in AT "can provide similar benefits for users."

[maryjom]

To Mitch's point #2 above regarding how the EN 301 549 applies clause 5.1 requirements to closed, but it also applies a number of WCAG criteria to closed functionality as well - which the Revised 508 Standards does not. Further, the EN applies 4.1.2 Name, Role, Value if the ICT is not closed to all assistive technology but it doesn't specify which types of AT or that they mean only assistive technologies that make use of programmatic information.

Regarding your 26 January proposal of adjusting the text. I like it...and wonder about a further tweak: "Built-in AT functionality can provide similar benefits for users."

[GreggVan]

The proposed language is a bit confused or confusing.
On a closed product - you cannot add AT. But the product may include AT. So software that is running on a closed product - is not itself closed -- and needs to do all of the things that software needs to do like making things programmatically determinable. If the software declares itself closed - then it cannot rely on the AT in the platform (e.g. phone) and must provide ALL of the functionality outlined in the 'closed functionality' provisions (of which we have none but the other guidelines do). you can't have it both ways and say 'I'm running on a closed product so I don't have to make my software accessible or worry about 4.1.2 and the other P.D. SC.

So - this applies as written to all software and non-web content.

then in the CLOSED section - just put it in with all the other P.D. provisions and treat them all with one statement.

"The following items all are designed to allow Assistive technologies to be able to access information from and operate controls of software. If a product has closed functionality, the software is responsible for providing similar access options to people with disabilities that their assistive technologies would provide if it were not closed. Since WCAG does not deal with closed products, you cannot find guidance on how to meet this requirement in WCAG or in this document. See other accessibility guidelines like EN 301 549 and 508 to find requirements on products with closed functionality. "

then we just need to list all the SCs that deal with "ensuring AT can access information and functionality. We do not need to repeat the above under each nor try to explain how to provide that equivalent functionality. That is at least a years work to do properly and other standards are currently wrestling with it.

[mraccess77]

Agree with Gregg. Closed products can have built in platform AT. Software on that platform then may be open or closed within that as well e.g games on a closed game console.