Closed Functionality Analysis

	A	B	C	D	E	F	G	H	I	J	K
1	WCAG Success Criterion (Level A and AA)	Problematic for: users of AT that relies on programmatic info (e.g. screen readers) (Yes/No)	Problematic for: users of alternative Keyboards (Yes/No)	Problematic for: users of speech input/control (Yes/No)	Problematic for: users of large text or screen magnification (Yes/No)	Problematic for: closed functionality software authors (Yes/No)	Problematic for: Testing on closed functionality products (Yes/No)	Comments Explain what are the problems that might not be so obvious, problems for specific conditions, or whatever comes to mind.	Current WCAG2ICT content for closed functionality	Is existing WCAG2ICT content sufficient? (Yes/No)	Comments and suggested updates for Closed Functionality guidance / text

2	Generic comments that apply across many or all SC							GVan: I have tagged all of the ones that relate to information being Programmatically determinable, or otherwise available to AT (that of course is not there). I think these should all be handled the same by saying somthing at the top of our documen. I provide a suggested text in column K: GVan2: I think we need to differentiate between the content in a closed product - and the underlying OS of the closed product. For example an iphone is closed - but it has AT in its platform - so content (including apps) need to meet many of these SC to work with that AT. Or maybe don't call those software closed since they run on a platform that has built in AT GVAN3: even where a closed product has proprietary software and content -- since the proprietary software needs to provide aT functionality - I think the CONTENT (written later by others) still needs to follow PD rules or it won't be accessible by the proprietary software. Perhaps we handle this with a global -- if AT is on the platform software should not be treated as being on a closed platform -- for those aspects provided by the platform - and only address those aspects not covered by the platform AT that would ordinarily be available. Mary Jo: I don't consider products with built-in AT software that users can turn on/off and customize/operate like a normal AT is fully closed. iPhone and iPad are examples of that.			GVAN: Text to go at top of Closed Product section "AT EQUIVALENCY: Since AT cannot be relied upon in a closed product - the affordances provided by AT need to be built into the closed product. This include the AT that would be used by different disabilltiies to access this information/functionality including visual, hearing, physical, and cognitive AT that would present the information in auditory, simplified, non-gesture, and other means. We are not in a position here to lay out all of the different AT that closed products should provide - but we note that the closing of a product removes all of these avenues for access that are available when information is available to AT. Rather than repeat this for every SC we simple say "see AT equivalency above" to refer to this comment. " Mary Jo: My alternative draft - Outside the WCAG2ICT Task Force, alternate requirements, specific to products with closed functionality, have and will continue to be developed to cover the intent of applicable SC that require programmatic information. Since assistive technology cannot be installed on closed functionality products, the software will need to build in additional functionality to ensure the product can be used by persons with different disabilities to access the information and functionality provided by the product.
3	1.1.1 Non-text Content	Bruce: Yes				Mary Jo: Yes Gvan:This is PD	Bruce: Yes	Mary Jo: Meaningful information conveyed in non-text content needs to be made available via a means that doesn't require AT or programmatic information.	requires text or a text alternative	No	Gvan: This is the same as other PD (programmatically determinable) items. Bruce: Many closed products will need be speech enabled in order to be useable by users without vision. I am not creative enough to see how to get that from WCAG 2 at all, and even with WCAG2ICT it seems out of scope (unfortunately). Consensus 24th May: Modify existing guidance to: requires text or a text alternative in a programmatically determinable form
4	1.2.1 Audio-only and Video-only (Prerecorded)					Mary Jo: Yes Gvan:This is PD		Mary Jo: If only a text alternative is provided, it would have to be available in a way that meets a variety of user needs (hearing, vision, cognitive)	requires a text alternative for time based media	Maybe	Consensus 24th May. Existing guidance is sufficient: requires a text alternative for time based media MJM: Thinking further, for video-only there is an option for providing an alternative, which could be a text alternative, so similar content to the note for 1.2.3 should be used: one of the options available to authors for success criterion 1.2.1 is that of providing a media alternative that is text—which necessarily relies on a connected assistive technology to be presented
5	1.2.2 Captions (Prerecorded)							Bruce: It might not be so obvious that SCCP which uses speech output is "prerecorded".		Yes	No text needed.
6	1.2.3 Audio Description or Media Alternative (Prerecorded)					Mary Jo: Yes Gvan: No or PD		Mary Jo: Ability to meet this SC using a media alternative is about providing a full-text transcript. This would necessitate some method to make the content of the transcript accessible to all users.	one of the options available to authors for success criterion 1.2.3 is that of providing a media alternative that is text—which necessarily relies on a connected assistive technology to be presented	Yes	Nothing additional needed.
7	1.2.4 Captions (Live)							Bruce: For SCCP, I think "live captions" would only be applicable for something like remote customer service.		Yes	No text needed.
8	1.2.5 Audio Description (Prerecorded)									Yes	No text needed.
9	1.3.1 Info and Relationships	Bruce: Yes				Mary Jo: Yes Gvan: This is PD	Bruce: Yes	Mary Jo: Programmatic information that would be conveyed to a user using AT (screen reader, or be available to voice control software, etc.) and the functionality those entail would have to be covered by other requirements. In the EN 11.1.3.1.2, it uses the same text requirement that is used for 1.3.2 Meaningful sequence which replaces this requirement.	requires information in a programmatically determinable form	Yes	Nothing additional needed.
10	1.3.2 Meaningful Sequence					Mary Jo: Yes		Mary Jo: Programmatic information that would dictate the order something is read to the user by AT would have to be handled by whatever internally controls the audio output so information is relayed in a meaningful order at the appropriate time. There isn't a concept like in the Web where all of the content on the screen is read out to the user, so I'm not sure this SC makes sense to apply or would automatically be met by closed functionality software the met the speech delivery coordination requirement. This is why 508 required 402.2.3 Speech Delivery Type and Coordination where speech is coordinated with whatever is displayed on the screen. The EN followed suit with 11.1.3.2.2 Meaningful sequence (closed functionality) that the auditory information allows the user to correlate the audio with the information displayed on the screen.	requires information in a programmatically determinable form	No	Consensus 24th May: requires information in a programmatically determinable form; a correct reading sequence should be output that helps user correlate information that is provided auditorially or through some other non-visual means with the corresponding information displayed on the screen.
11	1.3.3 Sensory Characteristics									Yes	No text needed.
12	1.3.4 Orientation (New in WCAG 2.1)					Phil, Mary Jo: Yes	Phil, Mary Jo: Yes	Phil Day. Closed functionality may often have hardware that is affixed in a certain position. As such, I would argue that the specific orientation is essential and therefore the clause is not relevant. Mary Jo. Another example of this is if there is only one particular orientation for affixed products (e.g. a printer can't be placed on its side, and it doesn't have a movable/rotatable display). In such a case, it would not make sense to require the software to allow different orientations.	In the guidance for the SC (not in the SC problematic for Closed Functionality section) we have: Content that is only used on hardware with a fixed display orientation OR that has no sensor to detect or change the orientation is covered under the essential exception and not required to provide support for orientation changes.	No	Content that is only used on hardware with a fixed display orientation OR that has no sensor to detect or change the orientation is covered under the essential exception and not required to provide support for orientation changes. OR instead simply point to the note in the main guidance. Some closed functionality products have fixed-in-place displays or other limitations to modifying the physical display orientation where the note in the section Guidance When Applying Success Criterion 1.3.4 to Non-Web Documents and Software would apply.
13	1.3.5 Identify Input Purpose (New in WCAG 2.1)					Mary Jo: Yes		Mary Jo: Likely that the platform programmatic support for identifying these fields does not exist, and even if it did, there's no AT to expose it to the user. So if there are specifics in the types of input and what specifically should be relayed to the user (in text and in audio), then these should be made into an alternate requirement (which the EN did).	requires information in a programmatically determinable form	No	requires information in a programmatically determinable form; text labels need to be specific and be provided to the user in other modalities (e.g. auditory).
14	1.4.1 Use of Color									Yes	No text needed.
15	1.4.2 Audio Control (Start here 31 May meeting)					Phil, Mary Jo: Yes	Phil: Yes Mary Jo: Maybe	Phil Day. Closed functionality products may allow audio to be interrupted (e.g. by the user selection of an option to move to the next 'screen') but this could be argued to be subtly different from pause or stop of the audio. Similarly, some closed systems may not allow differentiation between the overall system volume and the audio volume - they may only expose volume control to one of these features, not to both. Mary Jo: Since closed functionality products are required to voice what is happening, I'm assuming that is not considered "audio that plays automatically for more than 3 seconds"? IMO, this requirement conflicts /has no additional benefit to existing requirements for closed functionality products. Existing closed functionality requirements: 1) providing audio output of text information 2) Ability to pause or stop audio, and 3) Providing control over the volume (a single control, not separate from the overall system audio). The primary intent of the WCAG requirement is to prevent automatically playing audio sources from conflicting with the Screen Reader audio source or to prevent auto-play of audio content that would distract the user. Since the equivalent to Screen Reader output for closed functionality software is the required audio output for text, this would only be applicable if there is other auto-playing audio output other than the required audio output provided that replaces the screen reader.		No	Mary Jo proposed content: There are existing closed functionality requirements in standards such as the EN 301 549 and U.S. Revised 508 Standards that cover volume control for closed functionality products. Since there is no AT (by definition) in a closed functionality product, there is no potential for conflict between self-voiced content and screen reader audio. To avoid potential conflicts between the volume control requirements, this WCAG requirement should not be applied to closed functionality software.
16	1.4.3 Contrast (Minimum)					Phil: No Mary Jo: Yes	Phil, Mary Jo: Yes	Phil Day. Contrast may be difficult to test on a closed functionality product if the architecture has several layers of abstraction, or multiple layers of vertically stacked user interface elements with transparency. In this case, attempting to photograph the display may not give representative results; the testing should occur during content creation. Mary Jo: For implementation, the same issues apply as for non-text contrast. Some closed products do not have ability to have software control over the contrast (limited or no color choices or contrast adjustments under software control). Suggest similar notes to what we developed for non-text contrast be used.		No	Mary Jo: From the notes for 1.4.11 Non-text contrast: There are cases where applying this Success Criterion to non-web software on closed functionality products is problematic: - When the appearance of the content is determined by the hardware and not modifiable by the software author, the non-web software would meet the exception for this Success Criterion. NOTE: Hardware requirements for contrast are out of scope for WCAG2ICT (and this Success Criterion), but do exist in other standards' requirements for closed functionality products (e.g. EN 301 549 and Revised 508 Standards). - When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement. NOTE: Photographs are not sufficient for testing that content meets this Success Criteria. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.
17	1.4.4 Resize Text					Phil, Mary Jo: Yes	Phil: Yes	Phil Day. Some closed functionality products do not allow resizing of text. In this case, a minimum text size could be a sensible alternative provision, e.g. using US ADA section 707.7.2 Characters. ... Characters shall be 3/16 inch (4.8 mm) high minimum based on the uppercase letter “I”. ... Mary Jo: Both 508 and the EN 301 549 replace this requirement. The EN 301 459 5.1.4 specifies that the non-accented capital letter H subtends an angle of 0.7 degrees at a particular viewing distance instead of applying this SC.	because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author	Mary Jo: No	because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author. NOTE: The EN 301 549 and U.S. Revised Section 508 requirements have replaced this requirement with a minimum text size requirement for closed functionality software. WCAG2ICT supports that approach.
18	1.4.5 Images of Text					Mary Jo: Yes		Mary Jo: This requirement is replaced in the EN 301 549 by 5.1.3.6 Speech output for non-text content and points to SC 1.1.1 for the guidance for the "text alternative". IMO, that's a bit odd because 1.1.1 for closed functionality points back to 5.1.3.6 Speech output, so adds no further context, information, or requirements.	because there is no need to impose a requirement on all closed functionality that text displayed on the screen actually be represented internally as text (as defined by WCAG 2.2), given that there is no interoperability with assistive technology	Yes	No additional text needed.
19	1.4.10 Reflow (New in WCAG 2.1)					Phil, Mary Jo: Yes	Phil: Yes	Phil Day. Some closed functionality products do not allow the user to manipulate the interface, and therefore reflow is not possible). Mary Jo: Some closed functionality products also do not display chunks of text and only have UI controls (e.g. printers, point-of-sale machines, etc.). In such cases, two-directional scrolling to access the text and the UI controls may be considered essential.		No	Many closed functionality products do not allow users to modify the viewport or change font sizes, so there would be no need to impose a requirement on all closed functionality that content is able to reflow. Additionally, many closed functionality products do not display large chunks of text and only have UI controls. In such cases, two-directional scrolling to access the text and UI controls may be considered essential.
20	1.4.11 Non-text Contrast (New in WCAG 2.1)					Phil: No Mary Jo: Yes	Phil, Mary Jo: Yes	Phil Day. Contrast may be difficult to test on a closed functionality product if the architecture has several layers of abstraction, or multiple layers of vertically stacked user interface elements with transparency. In this case, attempting to photograph the display may not give representative results; the testing should occur during content creation. Mary Jo: As the guidance we developed says, not all closed functionality hardware has programmatic ability to choose colors/contrast - may be hardware driven and specific to the display used. Alternate requirements on hardware might be necessary. I think the notes we developed for WCAG2ICT are sufficient.	There are cases where applying this Success Criterion to non-web software on closed functionality products is problematic: When the appearance of the content is determined by the hardware and not modifiable by the software author, the non-web software would meet the exception for this Success Criterion. NOTE Hardware requirements for contrast are out of scope for WCAG2ICT (and this Success Criterion), but do exist in other standards' requirements for closed functionality products (e.g. EN 301 549 and Revised 508 Standards). When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement. NOTE Photographs are not sufficient for testing that content meets this Success Criteria. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.	Yes	No additional text needed.
21	1.4.12 Text Spacing					Phil, Mary Jo: Yes	Phil: Yes	Phil Day. Some closed functionality products do not support these text style properties and therefore cannot meet this clause Mary Jo: IMO, it is rare or nonexistent that closed functionality products are implemented using markup languages. If there are, do any support modifying text style properties (by the user and/or by the software)? If not, then it would automatically meet this requirement. There should probably be some note to this effect. EN 301 549 seems to except any software that has a fixed size content layout area from meeting this requirement. That seems an odd exception, as the requirement doesn't talk about the content layout area (was this clause meant for 1.4.11 Reflow?), it's about when the user changes text size or spacing that there is no loss of information or functionality.		No	Closed functionality software is unlikely to be implemented using markup languages, and is also unlikely to support modification of line line, paragraph, letter or word spacing.
22	1.4.13 Content on Hover or Focus (New in WCAG 2.1)					Mary Jo: Yes		Mary Jo: Do closed functionality products have any capability of having content that appears on hover or focus? If not, the software would automatically meet this criteria (really it shouldn't even be applied) - just another requirement to think about, understand, and give a "meets" answer without having to do anything. EN applies this as-is. Phil: Systems that use hover for long press (either as an accessible alternative to double tap, or for systems with limited numbers of options such as a very small touchscreen, where long press might be used to trigger other actions) - would this count as hover behaviour? I would argue that it should not, but would like clarity from the TF. Mary Jo response to Phil: Content on hover or focus is content that would appear on hover/focus that would then disappear when hover or focus is removed (Some web examples are: tooltips and definitions). I wouldn't consider a long press as a hover action. We could talk about that in a note though - clarify that a long press is not the same as a hover. In addition, I imagine that after a long-press and new content appears, it doesn't auto-dismiss when you lift your finger which is the problem they are trying to solve with this SC.		No	Most closed functionality software doesn't have the concept where receiving and removing pointer hover triggers or hides content. Therefore, there is no need to impose this requirement on all closed functionality software.
23	2.1.1 Keyboard					Mary Jo, Phil: Yes		Mary Jo: For closed functionality, the EN 301 549 provides an alternative requirement which points to 5.1.6.1 Operation without a keyboard interface, which simply points to 5.1.3 Non-visual access. 5.1.3 is a combination of 16 requirements about non-visual access to ICT. IMO, this is a mismatch, as the WCAG requirement is for ensuring when there is a keyboard that all functionality is operable using the keyboard. For closed functionality products, there might be an on-screen keyboard or a modified keyboard (e.g. alphanumeric only) with other functionality buttons, or no keyboard at all. Having all functionality being operable using a keyboard doesn't make sense here, so this should simply not be applicable. I do agree there should be alternate requirements for non-visual access. Keyboard access isn't just for the blind, but also for people with physical disabilities that might use voice control/voice input software, switches, and and other alternate input methods. Phil: Agree with Mary Jo's notes above. For closed functionality, it could be more helpful to require tactilely/tactually discernible input for all functions, with prescribing whether this is to be achieved with a keyboard or some other means.	requires operation via a keyboard interface which allows alternative input devices	No	Mary Jo proposed text: there is no need to impose this requirement on all closed functionality software. Many closed functionality products do not have a keyboard or have a partial keyboard, such as a numeric keypad. Functions are often available using tactilely discernable buttons or fulfill this requirement through alternate means that are covered by specific requirements for closed functionality products. Issue for the EN 301 549: Need to open an issue on the EN 301 549 for its replacement of this requirement with 16 requirements for non-visual access which goes far beyond simply keyboard access.
24	2.1.2 No Keyboard Trap					Mary Jo: No		Mary Jo: Not all closed functionality products even have a keyboard, or may have a partial keyboard - not used for navigation (e.g. numeric keypad). In such cases, this requirement would be automatically met, as a keyboard trap is not possible.		Yes	No text needed.
25	2.1.4 Character Key Shortcuts (New in WCAG 2.1) (end 31 May)							Mary Jo: EN has an alternate requirement 5.1.6.1 (Operation without a keyboard interface) when the non-web software is "closed to keyboards or keyboard interface". IMO, this extends closed functionality beyond AT. A keyboard isn't AT. This should simply apply as written. IF there is a keyboard, you wouldn't want any single key character key shortcuts to affect any text input fields. If there is no keyboard in the closed functionality product, then this would automatically be met.		Yes	No text needed.
26	2.2.1 Timing Adjustable					Phil: Yes Mary Jo: No		Phil: In some cases, a closed system may allow extending the time within some limits, but not up to 10x, with at least 20s between estensions as stipulated here, as this could have security implications (e.g. timeout on an ATM is there to protect a user who authenticates, does an action, then gets distracted and forgets to exit). Mary Jo: I think time limits regarding security would fall under the essential exception already written into the 2.2.1 requirement. Do we need to reiterate that in the notes for closed functionality?		Yes	No text needed.
27	2.2.2 Pause, Stop, Hide					Phil, Mary Jo: Yes		Phil: What about Closed systems that use animation or video to accompany text for instructional purposes (e.g. where to find the payment device or card reader)? I would argue that these should be excluded as the animated content already has a text alternative, but this clause seems to suggest that any animation should be possible to pause, stop or hide. Mary Jo: EN doesn't have specific notes on this for closed functionality. Perhaps most animations on closed functionality products would be considered essential.		Yes	No text needed.
28	2.3.1 Three Flashes or Below Threshold									Yes	No text needed.
29	2.4.1 Bypass Blocks					Phil: Yes		Phil: Closed systems may not have this feature, but the content should instead be authored to avoid repitition where it is not needed		No	The WCAG2ICT interpretation of this SC replaces "sets of Web pages" with "set of software programs" which is extremely rare - especially for Closed functionality software. However, being able to bypass blocks of content that are repeated within software is generally considered best practice.
30	2.4.2 Page Titled							Notes from our meeting: We need to extend the note because many closed functionality products focus each view of screen content to a single function - like asking a single question. Adding a page title for each would be distracting and take the user more time to take action and complete transactions.	where software is an integral part of hardware that provides a single function, such as a calculator or IP telephone, there is no need for a title	No	Where software is an integral part of hardware that provides a single function, such as a calculator or IP telephone, there is no need for a title. In addition, a software program does not equate to a "page" or "screen" of content that is a step in a process. Closed functionality products often break processes down to a series of screens, each with a single function. Requiring a page title for each would be distracting and take the user more time to take action and complete transactions.
31	2.4.3 Focus Order									Yes	No text needed.
32	2.4.4 Link Purpose (In Context)									Yes	No text needed.
33	2.4.5 Multiple Ways					Phil: Yes		Phil: Closed systems may not support multiple ways to locate content (analagous to a web page); there is often an implicit process (e.g. based around a transaction), and the flow may be limited to a single path. I would argue that this means that the exception would apply, but suspect we will need to add a note to comment that the exception applies more broadly than just to web pages that are part of a process		No	The WCAG2ICT interpretation of this SC replaces "sets of Web pages" with "set of software programs" which is extremely rare - especially for Closed functionality software. There are a number of notes in the section Guidance When Applying Success Criterion 2.4.5 to Non-Web Documents and Software that are applicable to closed functionality software.
34	2.4.6 Headings and Labels									Yes	No text needed.
35	2.4.7 Focus Visible (New in WCAG 2.1) (Changed in WCAG 2.2)					Mary Jo: No	Mary Jo: No	Mary Jo: This doesn't have specific "visible" measurements. Though subjective, it is subjective for all testing this and for all types of software.		Yes	No text needed.
36	2.5.1 Pointer Gestures (New in WCAG 2.1) (start 7 June)					Mary Jo: No	Mary Jo: No	There may eventually be single pointer gestures for pin entry, but this would apply.		Yes	No text needed.
37	2.5.2 Pointer Cancellation (New in WCAG 2.1)					Mary Jo: No	Mary Jo: No	Mary Jo: The note on the "essential" pointer cancellation example definitely applies in closed functionality products. Do we need to repeat that text for the closed functionality section? Here's the quoted text: [Examples of essential functionality for non-web software are features for meeting environmental energy usage requirements (like waking a device from sleep, power saver mode, and low power state).]		No	There are cases in closed functionality software where there are essential features that would meet the exception to this success criterion. Examples include features for meeting environmental energy usage requirements (like waking a device from sleep, power saver mode, and low power state).
38	2.5.3 Label in Name (New in WCAG 2.1)					Mary Jo: Yes	Mary Jo: No	Mary Jo: Programmatic label contains the same text as the visual label. Definition of "closed" means there isn't AT to surface the programmatic label.	requires information in a programmatically determinable form; specifically, the programmatic name contains the text of the visual label	Yes	No changes needed.
39	2.5.4 Motion Actuation (New in WCAG 2.1)					Mary Jo: No	Mary Jo: No	There are gestures by the user (not necessarily on a touch screen but in the air) used to wake up the machine, reset a session, or navigate. There is also the possibility of proximity detection to wakup the machine or reset a session, or navigate and interact through gestures.		No	Motion used as a security feature, such as resetting a session, is considered essential for the function; therefore, it does not need to support the ability to be turned off.
40	3.1.1 Language of Page					Mary Jo: Yes		Mary Jo: Requires programmatic information. Language is typically a preference setting for the software.		No	requires information in a programmatically determinable form; for closed functionality user settings for language are typically used to set the UI language.
41	3.1.2 Language of Parts					Mary Jo: Yes		Mary Jo: Requires programmatic information. Since there is no AT, and language settings are typically applicable to the entire closed functionality software/UI, mixed languages may not be easily supportable by closed functionality software.	requires information in a programmatically determinable form	No	requires information in a programmatically determinable form; support for correct pronunciation of other languages would require alternate means to produce correct pronunciation.
42	3.2.1 On Focus					Mary Jo: No	Mary Jo: No			Yes	No text needed.
43	3.2.2 On Input					Mary Jo: No	Mary Jo: No			Yes	No text needed.
44	3.2.3 Consistent Navigation					Mary Jo: No	Mary Jo: No	Set of web pages situation...		No	This SC is interpreted to only apply to "sets of software programs" which is very rare. See the second note in the WCAG2ICT guidance for SC 3.2.3 Consistent Navigation.
45	3.2.4 Consistent Identification					Mary Jo: No	Mary Jo: No	Set of web pages situation...		No	This SC is interpreted to only apply to "sets of software programs" which is very rare. See the second note in the WCAG2ICT guidance for SC 3.2.4 Consistent Identification.
46	3.3.1 Error Identification					Mary Jo: Yes	Mary Jo: No	Mary Jo: Seems that there would need to be a combination of visual indication of the error as well as auditory identification. Interesting that the EN only points to a non-visual error identification requirement as a replacement for this: See 5.1.3.15 Non-visual error identification. I'm not exactly sure I agree with what was originally written for WCAG2ICT. I think the indication may not need to be in text, but a visual (and auditory) indication of some sort would be needed because simply an auditory indication of errors wouldn't meet the needs of persons who are deaf or hard of hearing.	while it's important for errors that can be detected to be described to the user, for closed functionality, the error description doesn't have to be provided in text, as defined in WCAG 2.2	Yes	No text needed. Give feedback to the AG and to the EN on this.
47	3.3.2 Labels or Instructions					Mary Jo: No	Mary Jo: No			Yes	No text needed.
48	3.3.3 Error Suggestion					Mary Jo: No	Mary Jo: No			Yes	No text needed.
49	3.3.4 Error Prevention (Legal, Financial, Data)					Mary Jo: No	Mary Jo: No			Yes	No text needed.
50	4.1.1 Parsing (obsolete and removed) (Removed in 2.2)					Mary Jo, Phil: Yes	Mary Jo: Yes	Mary Jo: This is parsing of markup - very technology-specific. Is now obsolete & removed in WCAG 2.2, and notes being added to WCAG 2.0 and 2.1 so should not be applied to closed functionality. The whole point of this was so AT would have consistent results. IMO this should never have been applied to closed functionality software. Phil: Agree - can not apply to closed functionality as it may not parse HTML	the Intent of 4.1.1 is to provide consistency so that different user agents or assistive technologies will yield the same result	No	This requirement has been made obsolete and will be removed in WCAG 2.2.
51	4.1.2 Name, Role, Value					Mary Jo: Yes	Mary Jo: Yes	Mary Jo: Same as the note, requires programmatic identification of Name, role, and value that would need some other requirement to reveal to the user without the use of AT.	requires information in a programmatically determinable form	No	requires information in a programmatically determinable form; some other mechanism would be needed to contextually reveal needed information to the user.
52	4.1.3 Status Messages (New in WCAG 2.1)					Mary Jo: Yes	Mary Jo: No	Mary Jo: The reliance of this SC on programmatic information, and that the content be implemented in markup languages would make this difficult to apply directly to closed functionality. In the absence of assistive technology (closed functionality), it is a best practice to have visual and non-visual indicators of status.	requires information in a programmatic determinable form. Additionally, software with closed functionality is not typically implemented using markup languages. NOTE Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.	Yes
53
54
55	Success Criterion (New in WCAG 2.2)	Problematic for: users of AT that relies on programmatic info (Yes/No)	Problematic for: users of alternative Keyboards (Yes/No)	Problematic for: users of speech input/control (Yes/No)	Problematic for: users of large text or screen magnification (Yes/No)	Problematic for: closed functionality software authors (Yes/No)	Problematic for: Testing on closed functionality products (Yes/No)	Comments Explain what are the problems that might not be so obvious, problems for specific conditions, or whatever comes to mind.	Current WCAG2ICT content for closed functionality	Is existing WCAG2ICT content sufficient (Yes/No)	Comments and suggested updates for Closed Functionality guidance / text
56								Phil: should this be 2.4.11 Focus Not Obscured (Minimum), or 2.4.13 Focus Appearance? I assume the former Mary Jo: Removed the Focus Appearance one. This was moved back to Level AAA in the latest iteration of WCAG 2.2 and the numbers changed around.
57	2.4.11 Focus Not Obscured (Minimum)					Mary Jo: No	Mary Jo: No	Mary Jo: This can apply, as written.
58	2.5.7 Dragging Movements					Mary Jo: No	Mary Jo: No	Mary Jo: This can apply, as written.
59	2.5.8 Target Size (Minimum)					Phil, Mary Jo: Yes	Phil, Mary Jo: Yes	Phil: Problematic due to using CSS pixels as previously discussed in reflow. Physical equivalents would greatly help in implementing this type of requirement. Similarly, testing may not be feasible by any other than the content creator Mary Jo: Agree, that closed functionality would more likely to not have any method of measuring size of targets using software, would likely not have any concept of device-independent pixels or CSS pixels, and often would be tied to a particular display (so the pixel density wouldn't be changeable). If there was a concept of pixel density-independent measures, recommend using that. Otherwise, a physical size fallback based on the research for fingertip size could be developed by a standards organization.		No	Need to say something along the lines of closed products - there is a large variety in display sizes and a lack of pixel density independent measurements, thus a physical measurement may be more useful. However, this should be defined in such a way as to still be feasible for devices with very small screens.
60	3.2.6 Consistent Help					Mary Jo: Yes	Mary Jo: No	Mary Jo: This is a "web page within a set of web pages" situation. If any of the covered help mechanisms (Human contact details; Human contact mechanism; Self-help option; A fully automated contact mechanism) are available, suggest in the general guidance for this SC that we have verbiage to the effect of: Although not required by this success criterion, ensuring that availability of the covered help mechanisms be consistently presented when they occur more than once within non-web documents or software programs directly addresses user needs identified in the Intent section for this Success Criterion, and is generally considered best practice.
61	3.3.7 Redundant Entry					Phil, Mary Jo: No	Phil, Mary Jo: No	Phil: Closed systems may not allow auto fill for security reasons, but this is already covered in the WCAG 3.3.7 exceptions
62	3.3.8 Accessible Authentication (Minimum)					Phil, Mary Jo: Yes	Phil: Yes Mary Jo: No	Phil: I suspect this was written to cover CAPTCHA, but it could be argued that a personal identification number (PIN) such as is used for all ATM transactions, and also used with all smart chip cards, would fail this requirement as there is no alternative that is allowed by the relevant security standards. Mary Jo: The first bullet of the definition of "cognitive function test" seems it would include entering a PIN. The rest of the examples in the definition would likely not pertain to closed functionality, so are not a problem. I have no awareness of any way around providing a PIN for transactions, as these are important/required for security purposes.
63
64	Not a focus for WCAG2ICT this round, but in case you want to notate any thoughts as you're going through WCAG.
65	Success Criterion (Level AAA)	Problematic for: users of AT that relies on programmatic info (Yes/No)	Problematic for: users of alternative Keyboards (Yes/No)	Problematic for: users of speech input/control (Yes/No)	Problematic for: users of large text or screen magnification (Yes/No)	Problematic for: closed functionality software authors (Yes/No)	Problematic for: Testing on closed functionality products (Yes/No)	Comments Explain what are the problems that might not be so obvious, problems for specific conditions, or whatever comes to mind.	Current WCAG2ICT content for closed functionality	Is existing WCAG2ICT content sufficient (Yes/No)	Comments and suggested updates for Closed Functionality guidance / text
66	1.2.6 Sign Language (Prerecorded) Level AAA
67	1.2.7 Extended Audio Description (Prerecorded) Level AAA
68	1.2.8 Media Alternative (Prerecorded) Level AAA
69	1.2.9 Audio-only (Live) Level AAA
70	1.3.6 Identify Purpose Level AAA (New in WCAG 2.1)					Mary Jo: Yes	Mary Jo: Yes	Mary Jo: Issues are that this SC is limited to "content implemented using markup languages", and making the purpose programmatically available. So the purpose would need to be relayed in some other non-programmatic way.
71	1.4.6 Contrast (Enhanced) Level AAA					Phil, Mary Jo: Yes	Phil, Mary Jo: Yes	Phil: Use of point sizes to differentiate large text is not always meaningful as this is a relative measure when used in software, and has even varied through the history of print. It may be necessary to provide an equivalent physical measure, or at least the assumed resolution to allow somebody to then convert (e.g. in print 72 points equals 1 inch) Mary Jo: In addition to Phil's point, this has the same potential issues with the capability of the hardware that allows the software author to modify color/contrast to meet this requirement as well as the testing issues documented in the closed functionality section for SC 1.4.11 Non-text Contrast
72	1.4.7 Low or No Background Audio Level AAA
73	1.4.8 Visual Presentation Level AAA					Phil, Mary Jo: Yes		Phil: Closed systems may not allow refactoring of onscreen content due to system architecture, security, or other constraints. An alternative may need to be suggested (e.g. instead of scaling to 200%, a minimum text size as used in the ADA could be proposed instead). See, for example, ADA section 707.7.2, 'Characters shall be 3/16 inch (4.8 mm) high minimum based on the uppercase letter “I”.' https://www.ada.gov/law-and-regs/design-standards/2010-stds/#707-automatic-teller-machines-and-fare-machines
74	1.4.9 Images of Text (No Exception) Level AAA					Mary Jo: Maybe	Mary Jo: No	Mary Jo: Seems like this could be applied as-is. Are there cases, like in document printing, where the image of text is showing what the printed page looks like (positioning on the page) where this would be essential? i.e. it is not intended to be read in that format, but is just for demonstrating what something would look like prior to taking further action.
75	2.1.3 Keyboard (No Exception) Level AAA					Phil, Mary Jo, Sam: Yes	Phil: Yes	Phil: Some closed systems may not contain a keyboard. It may be more helpful to require tactilely discernible input rather than stipulate a particular implementation such as a keyboard Mary Jo: Agree with Phil - the reasoning is similar/same as for 2.1.1 Keyboard
76	2.2.3 No timing Level AAA					Mary Jo: Yes		Mary Jo: Timing could be essential, especially for security, where there has to be timeouts to prevent transactions from being appropriately ended due to inactivity. IMO, whenever closed functionality software has security-based timeouts those should not be held to meeting this SC.
77	2.2.4 Interruptions Level AAA					Phil: Yes		Phil: Some closed systems have to impose timing on a session for security reasons (e.g. at an ATM to prevent somebody else from withdrawing cash from your account). A mechanism should be provided to extend this time rather than requiring no timing at all
78	2.2.5 Re-authenticating Level AAA					Phil, Mary Jo: Yes		Phil: Again, some closed systems cannot meet this requirement as it contravenes the security rules (e.g. PCI rules for ATMs, or for card payment devices) Mary Jo: In the current SC, there is no "essential exception", so an exception would have to be added before applying to all closed functionality software.
79	2.2.6 Timeouts Level AAA (New in WCAG 2.1)					Mary Jo: Yes		Mary Jo: Security requirements for some types of transactions (Point-of-sale, ATM, ticketing, etc.) might require the software to have timeouts. Not sure if the length of time is specified in any of the security requirements or regulations and if the length of timeout changes by type of transaction or local regulations. Does surfacing the length of the timeout to the user ahead of time cause any issues? There are often cases where user data cannot be saved for more than 20 hours.
80	2.3.2 Three Flashes Level AAA					Mary Jo: No		Mary Jo: Easy enough to avoid flashing content - especially when it is for a certain amount of the overall screen or viewing angle.
81	2.3.3 Animation from Interactions Level AAA (New in WCAG 2.1)					Mary Jo: No		Mary Jo: Content can be designed to avoid using animations unless they are essential to help or demonstrate how the user needs to interact (e.g. essential animation for showing insertion of a credit or debit card).
82	2.4.8 Location Level AAA					Mary Jo: Yes		Mary Jo: Uses "set of web pages". Since we replace "set of web pages" with "set of software programs". This wouldn't be the case in closed functionality software where a set of software programs is highly unlikely to exist.
83	2.4.9 Link Purpose (Link Only) Level AAA					Mary Jo: Yes		Mary Jo: would have to be accomplished through the link text alone, as one could not provide a programmatic link text beyond that since it is closed functionality software.
84	2.4.10 Section Headings Level AAA					Mary Jo: Yes		Mary Jo: Some closed functionality software breaks steps of transactions down so far that requiring section headings to be provided would add to the cognitive load of completing each step in the process.
85	2.4.13 Focus Not Obscured (Enhanced) Level AAA (New in WCAG 2.2)					Mary Jo: No		Mary Jo: This is an SC where it is unlikely to even happen in many closed functionality products that may not have any concept of overlaying or overlapping content.
86	2.5.5 Target Size (Enhanced) Level AAA (New in WCAG 2.1)					Phil, Mary Jo: Yes	Phil, Mary Jo: Yes	Phil: Problematic due to using CSS pixels as previously discussed in reflow. Physical equivalents would greatly help in implementing this type of requirement. Similarly, testing may not be feasible by any other than the content creator
87	2.5.6 Concurrent Input Mechanisms Level AAA (New in WCAG 2.1)					Mary Jo: Yes	Mary Jo: No	Mary Jo: Closed functionality, by definition, is closed to alternative input mechanisms. In such cases, this SC cannot be met by the closed functionality software.
88	3.1.3 Unusual Words Level AAA					Phil, Mary Jo: Yes	Mary Jo: No	Phil: Closed systems might not support the addition of a mechanism to identify definitions of words/phrases. Instead, in a closed system the content author should be encouraged to either not use unusual words, or to define them at the first time of usage.
89	3.1.4 Abbreviations Level AAA					Phil, Mary Jo: Yes	Mary Jo: No	Phil: Closed systems might not support the addition of a mechanism to identify definitions of abbreviations. Instead, in a closed system the content author should be encouraged to either not use abbreviations, or to define them at the first time of usage.
90	3.1.5 Reading Level Level AAA					Mary Jo: Maybe	Mary Jo: Yes	Mary Jo: Reading level may not be achievable on all closed functionality products, as they may have specific technical useage and terminology that is outside the lower secondary-level vocabulary. For example, graphing calculators. For testing, a closed functionality system would not have the mechanism to check reading level. So verbiage would have to be tested during design/development when text content is on a standard computer where the reading level checking tools are available.
91	3.1.6 Pronunciation Level AAA					Mary Jo: No	Mary Jo: No	Mary Jo: Unlikely to be a problem, as closed functionality is required to self-voice (outside of WCAG), so pronunciation would be handled by whatever self-voicing mechanism is used. Perhaps an alternate requirement that self-voicing mechanisms use correct pronunciation.
92	3.2.5 Change on Request Level AAA					Phil, Mary Jo: Maybe		Phil: Some changes in context may be necessary for security reasons in a closed system (e.g. prompt to enter PIN, or display and vocalise a prompt asking if the user needs more time). In both cases, I think that these meet the intent of this requirement, but could be argued to constitute a change of context that the user is not fully in control of. Mary Jo: It seems that a change of context would have to be scoped to not include error prompts, timeouts, etc. that could happen asynchronous to the user's task. Even for other non-web software this would be a problem.
93	3.3.5 Help Level AAA					Phil: Yes Mary Jo: No		Phil: Some closed systems may not support the use of context sensitive help; where this additional information could make the experience much more difficult (e.g. when stepping through the steps of a transaction). Mary Jo: The definition of "context sensitive help" says that "Clear labels can act as context-sensitive help." So if the labels are clear, this could easily be met in closed functionality software.
94	3.3.6 Error Prevention (All) Level AAA					Mary Jo: No	Mary Jo: No
95	3.3.9 Accessible Authentication (Enhanced) Level AAA (New in WCAG 2.2)					Phil, Mary Jo: Yes		Phil: As before, the use of a personal identification number (such as a PIN) is mandated for use with ATMs, and other card payment devices that use smart chip cards. This requirement conflicts with the established security requirements in these industries Mary Jo: Agree with Phil. Security requirements trump this, and PINs are a neccessary aspect.
96
97
98
99
100